Re: Why do we need to go with 128 bits address space ?

Simon Hobson <linux@thehobsons.co.uk> Tue, 20 August 2019 10:34 UTC

Return-Path: <linux@thehobsons.co.uk>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC1CC12001B for <ipv6@ietfa.amsl.com>; Tue, 20 Aug 2019 03:34:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 bxrPpPktEszK for <ipv6@ietfa.amsl.com>; Tue, 20 Aug 2019 03:34:51 -0700 (PDT)
Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D57A212001A for <6man@ietf.org>; Tue, 20 Aug 2019 03:34:50 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk
Received: from simons-macbookpro.thehobsons.co.uk (Simons-MacBookPro.thehobsons.co.uk [192.168.137.111]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id DF26C1BC37 for <6man@ietf.org>; Tue, 20 Aug 2019 10:34:43 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Subject: Re: Why do we need to go with 128 bits address space ?
From: Simon Hobson <linux@thehobsons.co.uk>
In-Reply-To: <10708d7b-a4bc-f9d8-a644-7c5617f5ebf3@gont.com.ar>
Date: Tue, 20 Aug 2019 11:34:42 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <889B235E-CD29-4B9F-A9B9-4C488952A184@thehobsons.co.uk>
References: <CAPTMOt+cGhBqHmT3yZVChv-PCMqxT-WPDcDdM3RuTc1TMfFeVg@mail.gmail.com> <4278D47A901B3041A737953BAA078ADE148C2FE4@DGGEML532-MBX.china.huawei.com> <10708d7b-a4bc-f9d8-a644-7c5617f5ebf3@gont.com.ar>
To: "6man@ietf.org" <6man@ietf.org>
X-Mailer: Apple Mail (2.2104)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/5JwfWz4rBwBb5cqRi1MFwGxTkNU>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Aug 2019 10:34:53 -0000

Fernando Gont <fernando@gont.com.ar> wrote:

>> Just a bit curious about, why NOW when today’s technologies (HW/SW
>> processing capabilities as well as the ever-increasing bandwidth) are
>> more advanced compared with those at 25 years ago, suddenly people
>> become very concern with the overhead and start questioning about the
>> “extra burden” caused by the packet address/header length…
> 
> One possible answer: IoT.

Possibly.
But consider that even the lowest spec IoT things these days are likely to have more resources (memory, processing, bandwidth) than even mid range desktops of 25 years ago.
When I think back to what I was doing back then, most of our customers weren't "online" or networked at all, where things were networked it was typically 230kbps (Apple's LocalTalk) to share a laser printer, a very small number had some ethernet and that was 10Mbps, we still measured RAM and disk capacities on MB, and CPU speeds in MHz. I now carry around in my pocket a (not very up to date) mobile that has more of everything (more CPU, more memory, more storage, more pixels of more colours, more connectivity) than any of the systems I was installing for customers back then.

If people are using IoT and lack of resources as a reason for wanting to reduce the size of IP addresses, then it's because they've become lazy and profligate with resource usage, not because there's actually any real limitation.

But as has already been said a while ago - both in this thread and the other recent one - the ship for this discussion sailed a quarter century ago and it's not coming back.