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: irtf-discuss@ietfa.amsl.com
Delivered-To: irtf-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3609F120113 for <irtf-discuss@ietfa.amsl.com>; 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 qBjiz3RG9O5Y for <irtf-discuss@ietfa.amsl.com>; Fri, 16 Aug 2019 16:32:15 -0700 (PDT)
Received: from mail-ot1-x344.google.com (mail-ot1-x344.google.com [IPv6:2607:f8b0:4864:20::344]) (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 CD35E1200F5 for <irtf-discuss@irtf.org>; Fri, 16 Aug 2019 16:32:15 -0700 (PDT)
Received: by mail-ot1-x344.google.com with SMTP id f17so11147111otq.4 for <irtf-discuss@irtf.org>; 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=j9OMlZtVExl1Z7ECx2PKaGN6O9EVNV8MwEfaxgPpFKqqLdC7iMcjWM6iW18D0C6zoH BmoYSSCByWR/jMQtQ5dgp3413z0Wy1ZTm+Ar+k05QhE41qI7ZU42B2lLLYXnppQ6jHFU 79luCK4FYHomUjsnoZYOki8H+6Tko4uBAPGk8bCUeqyekhr8r74JblGJ6tS7sN/9g3zH yL7n3OFrJNPvPJYW3POhe9hk0ThPo0sZ290yOuOohs0NF+XbHi2NfgJDm8PVQvMPUbgu W/OKbNJOiH1JvrSB6SUBYwYqcLNUPWq02W5A5iQ5yzuCAhTu6V5CNJOiMV+mFjuSEf16 sNjA==
X-Gm-Message-State: APjAAAWTf24bnHvOMcorXwqkoPLSuDxwfvq00aWAd+stp4WstqHezTYC a3Mzy1gxLfORMcPWQxrlGnIK8F82rb8NoC/CjhU=
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>
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/irtf-discuss/o_cWAQ02pBYR8_gfek0pQdQ7EVg>
Subject: Re: [irtf-discuss] Why do we need to go with 128 bits address space ?
X-BeenThere: irtf-discuss@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IRTF general and new-work discussion list <irtf-discuss.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/irtf-discuss>, <mailto:irtf-discuss-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/irtf-discuss/>
List-Post: <mailto:irtf-discuss@irtf.org>
List-Help: <mailto:irtf-discuss-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/irtf-discuss>, <mailto:irtf-discuss-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Aug 2019 23:32:18 -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
> --------------------------------------------------------------------
>