Re: [v6ops] Are we competitive?

Nick Buraglio <buraglio@es.net> Fri, 29 July 2022 17:16 UTC

Return-Path: <buraglio@es.net>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E997AC15A726 for <v6ops@ietfa.amsl.com>; Fri, 29 Jul 2022 10:16:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=es.net
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2RFPf8T9CBD for <v6ops@ietfa.amsl.com>; Fri, 29 Jul 2022 10:16:43 -0700 (PDT)
Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB378C15A72F for <v6ops@ietf.org>; Fri, 29 Jul 2022 10:16:43 -0700 (PDT)
Received: by mail-pg1-x532.google.com with SMTP id 206so995160pgb.0 for <v6ops@ietf.org>; Fri, 29 Jul 2022 10:16:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=es.net; s=esnet-google; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=gVvRfrX71hw104vla+m8iQixQubA3XM0BPRzl/VOtQg=; b=VgJIlOK5Cq2wBRk0ilPhZHMTOEM8NsBci0zRuCynV/F+u/xWO2IKkq+co/ByZI3aDX rDiQKtPgWLLkqWsAXuej1kLPZsABRxBsK+oecidjeVKKkv3O1yH09FQupKsZ+Er2DQbn e5O0G32MPhFSERLsronYOhqHyIIc7xpmqVcV6Q3NpIG3Egbsx+3gQ4gJ3L+VaENQzA7w eNSJFHcRilzEuDcz2739VxXWdMXvWxO3Kt+O0iNSxbhJeeYOUu1bW7EMXAdWOvScySxW 83v4salz4rPUHZkvXQZm6+BEGNlaVESYWzOA1ZfOeadMvUXbzX0gnOabwmOri394ByfF OiOQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=gVvRfrX71hw104vla+m8iQixQubA3XM0BPRzl/VOtQg=; b=waFvhPaH4tUDJ5+IshW7TTjwsO8ORSp7QDwBMaOkAEwTtdHqR162Fg0SplSMZA4qRN DFJIbaIsoaKGL96d+/R6fBFekS1tSoc2mKKToh0zL262RHGP4Ig92hYgso6cTYt6sLwz 7UjMf7kBLkh48hMpNMSJMM3LdgkDlOA1t6FsBZGrSfHgzqUXgNCMb1e88yCQPKAMVYFt II1IjMVO9AprpOya6ZVen6j6SzoLd5cnK9ubOQ6Ws4whds6KTnzNtN4Phj6Ajej4m099 qT2+Vy5EPRsq6+5gx1JYZE3/L5gwIQvkam4KOgJousqN8Cy2PGHeFm3YLmlxcAYZgys0 BGpQ==
X-Gm-Message-State: AJIora8XESKQOro9yYTYZgRcO/KwBrD6iYMN9DCySPPgqvjnZJEkkjfc +b1G+FeZE8cb1CISR6BN6zeA7Blv8YaZ7Tq8vZQ6Wz/pO4VkWHdCv+N/mLvWpWN5XGvTjwB9hBC 3GNjcLtUPzfAFpYRD0oJxfatvmK5qaEAeBGlkvD3+Uo2wvwsDYTmXJ22c5aQ4GACRMUkEQeI4Un sSKI21
X-Google-Smtp-Source: AGRyM1v6OLwnKvBUSu0WbiL/wV8LBIGoBYi7Hxjjk7aabZkMSnsSMyjQqXbCSMld1bDF9a/s0HodOeO0PUUT4vrskh8=
X-Received: by 2002:a63:9041:0:b0:415:c0e8:c588 with SMTP id a62-20020a639041000000b00415c0e8c588mr3679560pge.282.1659115002317; Fri, 29 Jul 2022 10:16:42 -0700 (PDT)
MIME-Version: 1.0
References: <e4a35f0c-757a-aefa-c211-05b6015a4215@gmail.com> <YuJXbruluDmzF3RD@Space.Net> <ec68b29c62034d3e98adec9c5da45ff3@huawei.com> <25e4f9e4-e055-241c-7047-97dca8b09cc8@gmail.com> <3c35a91af90d4b82af724e7ce98378d3@huawei.com> <CAE=N4xcPq3CB5DDjPOk3oAqBfpJRebhXsFExSEAX_Yr3_XsSUg@mail.gmail.com> <97662d43-7daa-191c-792b-49a626fb9769@gmail.com>
In-Reply-To: <97662d43-7daa-191c-792b-49a626fb9769@gmail.com>
Reply-To: buraglio@es.net
From: Nick Buraglio <buraglio@es.net>
Date: Fri, 29 Jul 2022 12:16:30 -0500
Message-ID: <CAM5+tA_w9n2=cXc=mgsr8iOx2rndAWgPhnoNBs4UQnJd3gJxNA@mail.gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: Ed Horley <ed@hexabuild.io>, IPv6 Operations <v6ops@ietf.org>, Xipengxiao <xipengxiao=40huawei.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005b59c005e4f4d031"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/lRJIxEDCYM_WN-kLBIj2Srq9IvY>
Subject: Re: [v6ops] Are we competitive?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jul 2022 17:16:48 -0000

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 <brian.e.carpenter@gmail.com>
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=
> 40huawei.com@dmarc.ietf.org <mailto:40huawei.com@dmarc.ietf.org>> 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:brian.e.carpenter@gmail.com <mailto:
> brian.e.carpenter@gmail.com>]
> >     Sent: Thursday, July 28, 2022 5:05 PM
> >     To: Xipengxiao <xipengxiao@huawei.com <mailto:xipengxiao@huawei.com>>;
> Gert Doering <gert@space.net <mailto:gert@space.net>>
> >     Cc: IPv6 Operations <v6ops@ietf.org <mailto:v6ops@ietf.org>>
> >     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
> >     v6ops@ietf.org <mailto:v6ops@ietf.org>
> >     https://www.ietf.org/mailman/listinfo/v6ops <
> https://www.ietf.org/mailman/listinfo/v6ops>
> >
> >
> >
> > --
> > Ed Horley
> > ed@hexabuild.io <mailto:ed@hexabuild.io>| (925) 876-6604
> > 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
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>
ᐧ