Re: [irtf-discuss] Why do we need to go with 128 bits address space ?

Mark Smith <markzzzsmith@gmail.com> Fri, 16 August 2019 23:32 UTC

Return-Path: <markzzzsmith@gmail.com>
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 5023C120128; Fri, 16 Aug 2019 16:32:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.497
X-Spam-Level:
X-Spam-Status: No, score=-0.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 hrWoqyk0OaHK; Fri, 16 Aug 2019 16:32:15 -0700 (PDT)
Received: from mail-ot1-x342.google.com (mail-ot1-x342.google.com [IPv6:2607:f8b0:4864:20::342]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBF771200DE; Fri, 16 Aug 2019 16:32:15 -0700 (PDT)
Received: by mail-ot1-x342.google.com with SMTP id c34so11105659otb.7; Fri, 16 Aug 2019 16:32:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cekokHnSsNWLJvbyaU7rlyq8huhmLDIprA2loCKzP4o=; b=a2QckYUANYQQc3jDtuwfyIhWOQQYxq51aW6T3gCFTjKruMPEFftx/cO4Egvn2w9V70 sKYKTF9QhhwbHn7nrhXIT9JSnAP9F1mYSXJrJtz9BpUHY1u99aAfBRGzanElcKjxW2VI q4RF0ytFfQpfaOGRVcE7XU0t/ncC1rNZ40MQWG48M5Y2KmlGAeOy2WSfLlv0d0Nsfe89 Gk6rLOq30UK1vGSNu7GWZZPrf0AfXOBaQaUHvzkwBPOZx992ncYEhJ+AIadprIUXt3O1 cVKPlUTCeAPC1uJEY/0y2faU2VlKP9TpXoPYNUHbutKBi2X1iVPkL+FWS95p+XPmcQo+ RzOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cekokHnSsNWLJvbyaU7rlyq8huhmLDIprA2loCKzP4o=; b=A6HQZyb2xJyj6hkIaJHu60I2bdcniXsGV4VPOHNAug6rA2v6A1GqU7kGMykqdpqGF0 t5bAITKfL4eJLbhKrXth1Pt3JmQmZ8KrNPOUZHMNA4xhV1LYY7Z9HZsFClGBbAZtz3yL DwqeDLSMTjyZ4qTu7G24Ak9VkFbBInYA0up+PngPGxzDUy/cL7kgYQWGJlawDLmqFa0G Q+v5LWHZEShTrQFP110BSRGLy1OfSSovg3HEYewOznfIGnrra1HRXTIgd9IZPIlzqLmb QESjrvjZ25+yYlcYDxd+Oa2MS1GTvrgeIo3wixRRq4nXaveD+XI/R7lP75tJEUHDrPib j88A==
X-Gm-Message-State: APjAAAWTcTn+DQUeAb2yUqzRmAmnVhwvrP6YhUSHJgQVFJG4Z179BHmy krSsy0pvI3IX4m881o7VJEJmMWfH5xxlptdBdLI=
X-Google-Smtp-Source: APXvYqzsTEW7byUcxwoN8g/v0hYC9o8Kuxu/4Iex5GUZmyfLqoS05v0VCo7n8ydmYAxL8B2c5sQjhz7eYTjknpy78Xw=
X-Received: by 2002:a9d:7a5a:: with SMTP id z26mr8647969otm.348.1565998335038; Fri, 16 Aug 2019 16:32:15 -0700 (PDT)
MIME-Version: 1.0
References: <CAPTMOt+cGhBqHmT3yZVChv-PCMqxT-WPDcDdM3RuTc1TMfFeVg@mail.gmail.com> <cd254463-43ba-2afd-5c3c-f462a74e5c30@kit.edu> <CANMZLAat4X+Eh+fgTrbikO6dusvcvvUr5foj=3OEnbRhQtOHSw@mail.gmail.com> <CAMm+Lwi9QsW=QXc0fK=u-+PfM7fOhCyX2FugPfqPzghiwHAFcA@mail.gmail.com>
In-Reply-To: <CAMm+Lwi9QsW=QXc0fK=u-+PfM7fOhCyX2FugPfqPzghiwHAFcA@mail.gmail.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Sat, 17 Aug 2019 09:32:03 +1000
Message-ID: <CAO42Z2wtiGTpXab1G1BvmM1oCcC8drNKtEze5Xn+OM9ZRkY3eg@mail.gmail.com>
Subject: Re: [irtf-discuss] Why do we need to go with 128 bits address space ?
To: Phillip Hallam-Baker <phill@hallambaker.com>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, irtf-discuss@irtf.org, 6man@ietf.org, IETF discussion list <ietf@ietf.org>, shyam bandyopadhyay <shyamb66@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000007ab2d005904466ba"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/ZU_idj2z57-RSS3rh_rYmgkkdKY>
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: Fri, 16 Aug 2019 23:32:19 -0000

Incorrect.

On Sat., 17 Aug. 2019, 01:43 Phillip Hallam-Baker, <phill@hallambaker.com>
wrote:

> On Thu, Aug 15, 2019 at 6:31 AM Brian Carpenter <
> brian.e.carpenter@gmail.com> wrote:
>
>> e) 64 isn't enough to allow lots of bits for topology plus lots of bits
>> for privacy
>> f) in any case we can compress the headers in low power, low bandwidth
>> scenarios
>> g) it's 25 years too late for this discussion even if we were wrong
>>
>
> Perhaps.
>
>
> The reason we went to 128 bits was 64+64 = 128
>
> It was assumed that networks would want to map MAC addresses onto the
> lower bits of the address and those were already in the process of
> expanding to 64 bits. This hasn't happened because it is nonsense.
> Disclosing the structure of your internal network to potential attackers is
> stupid.
>
> IPv6 to IPv6 NAT is going to be seen as an essential security control in
> future zero trust/zero knowledge networks. I don't want Mallet knowing if I
> have 4 hosts in my network or 400 and I am going to try to make it as
> difficult and expensive as possible for him to find out. So instead of
> allocating one IPv6 address to my hosts, I will allocate multiple addresses
> and apply encryption to obfuscate them at the network boundary.
>
> This approach can provide a lot of leverage against DoS attacks. The Mesh
> service protocols make it possible for a Mesh service to assign each
> account a separate IPv6 address for client access. That in turn makes it
> possible for border controls to drop packets that are from accounts that
> are flooding or not associated with an account at all.
>
> It is easier to find an encryption cipher with a 64 bit block size than
> 48. They are not going to be any use for general purpose encryption but
> they would serve this one.
>
>
> It was also assumed that there was a need for more routable IP addresses
> which was probably a mistake.
>
> In IPv4, every host has an Internet has a routable address. So if Google
> has 32,368 hosts at the same site, that means 32,368 routable addresses.
> The design for IPNG did not take account of the fact that if we append a
> non-routable portion, those hosts can all sit on the same routable address.
>
> So yes, one could argue that 32+32 would have been enough. Only there are
> more than 4 billion people on the planet. So you have to have at least 40
> bits for the routable addresses and once you take account of inefficiency
> in the allocation process we need a minimum of 48 bits. Given the vast cost
> of the change, 64 bits looks like a reasonable choice to me.
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>