IETF Logo Mail Archive

Re: [v6ops] Thoughts about wider operational input

"Philipp S. Tiesel" <phils@in-panik.de> Wed, 30 March 2022 11:18 UTC

Return-Path: <phils@in-panik.de>
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 D23F53A0D6E for <v6ops@ietfa.amsl.com>; Wed, 30 Mar 2022 04:18:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.722
X-Spam-Level:
X-Spam-Status: No, score=-1.722 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.186, SPF_HELO_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGWGjPr7in-Y for <v6ops@ietfa.amsl.com>; Wed, 30 Mar 2022 04:18:31 -0700 (PDT)
Received: from einhorn-mail-out.in-berlin.de (einhorn-mail.in-berlin.de [217.197.80.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 228563A0D71 for <v6ops@ietf.org>; Wed, 30 Mar 2022 04:18:29 -0700 (PDT)
X-Envelope-From: phils@in-panik.de
Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de with ESMTPS id 22UBIOWk008319 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 30 Mar 2022 13:18:24 +0200
Received: from [2a0a:4580:1018:451:40c:9880:c969:7324] (helo=smtpclient.apple) by x-berg.in-berlin.de with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <phils@in-panik.de>) id 1nZWLH-00078K-Mf; Wed, 30 Mar 2022 13:18:23 +0200
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\))
From: "Philipp S. Tiesel" <phils@in-panik.de>
In-Reply-To: <1490078896.127608.1648636343527@mail.yahoo.com>
Date: Wed, 30 Mar 2022 13:18:23 +0200
Cc: Mark Smith <markzzzsmith@gmail.com>, JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org>, Brian E Carpenter <brian.e.carpenter@gmail.com>, v6ops list <v6ops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <857B9B98-597E-4FE6-BB3B-E62DD2FD7C0B@in-panik.de>
References: <52661a3d-75dc-111a-3f23-09b10d7cb8d4@gmail.com> <A72CDDDB-CDCE-4EAF-B95E-997C764DB2C4@gmail.com> <9175dc32-45c1-e948-c20a-3bcc958b77b9@gmail.com> <YjmJQMNgnJoSInUw@Space.Net> <D75EF08F-6A41-41B2-AFB2-649CBCC1D83E@consulintel.es> <CAPt1N1nRnYUFA=yyJHx6t52yqWbmcd2Tf1H8gQuCZBd3Q3VqJw@mail.gmail.com> <7F4AEB43-4B24-4A21-AE9D-3EB512B98C46@consulintel.es> <8fac4314b8244ba6b33eea68694296d0@huawei.com> <9A13E47B-75D0-443F-9EE9-D2917ACB2D0F@consulintel.es> <CAO42Z2xUG+BXj+VQpajed9aGjH+q-HR7RX7C-T4DsTbouz7xWQ@mail.gmail.com> <db66fe14-4391-b3ca-2219-e435d7e9cb28@gmail.com> <1490078896.127608.1648636343527@mail.yahoo.com>
To: "nalini.elkins@insidethestack.com" <nalini.elkins@insidethestack.com>
X-Mailer: Apple Mail (2.3696.80.82.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/U7KHDS8ALHHzZp5f1pI9iTEtezs>
Subject: Re: [v6ops] Thoughts about wider operational input
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 30 Mar 2022 11:18:36 -0000

Hi,


> On 30. Mar 2022, at 12:32, nalini.elkins@insidethestack.com wrote:
> 
> Brian,
> 
> >  Others have mentioned the OPEX cost of diagnosing NAT-induced problems even with the enterprise.
> 
> As someone who has been involved with diagnosing problems on enterprise networks for 30+ years, I can tell you the complexity of finding and solving problems with IPv6, adds a huge new and glorious dimension to troubleshooting.

Totally agreed, but IPv6 also eliminate a whole class of problems with overlapping RCF1918 spaces and unsolvable merging and integration scenarios. 

> Now, before people start telling me to convert to an IPv6-only network and such like, please stop.   Enterprises move at a snails pace and they are very risk-averse.   I can guarantee you that talk like that will only get you completely not listened to.  

I think it really depends on the use-case.

- If you try to sell IPv6 only in office networks, not getting listend to is rather a best case assumption.
- If you are setting up new server landscapes and are already out of RFC1918 space, IPv6 only becomes a serious consideration (perhaps with the addition of dual-stack load balancers and egress NAT64)  

The point is: IPv6 can be presented as a tool to solve problems or as a technology you may need to adopt in some distant future. Start with the former, only use the later as supporting argument. 

AVE!
   Philipp S. Tiesel

--  
Philipp S. Tiesel
https://philipp.tiesel.net/

v2.23.0 | Report a Bug | By Email