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

Phillip Hallam-Baker <phill@hallambaker.com> Fri, 16 August 2019 15:42 UTC

Return-Path: <hallam@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 DABBE12084F; Fri, 16 Aug 2019 08:42:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Level:
X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 vIimLLJrsklA; Fri, 16 Aug 2019 08:42:44 -0700 (PDT)
Received: from mail-ot1-f68.google.com (mail-ot1-f68.google.com [209.85.210.68]) (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 5606612082A; Fri, 16 Aug 2019 08:42:44 -0700 (PDT)
Received: by mail-ot1-f68.google.com with SMTP id w4so9900926ote.11; Fri, 16 Aug 2019 08:42:44 -0700 (PDT)
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=xECeXB0Z+ULBzFpxPLhONimktsN2+4hPJ1LedI3dwXs=; b=ZgHcfZrwWgbmXRhwifMoEM80gZ52Nj3xgqYtfTc6kDBSD8/IljHOcmCanlMkn2hozh ZicGX7DXFpC4WmqdenEv7s+JoSRArMDhc0KZUA8dRIi+yhLAyP8Eg5kpJUYynwZiVlBv DMs2etkgtN1QmHpyWA5qrSgE9vBX8k7TNor/gthQ16q7JxX/jPJNFCHXne7UEyr+rrPd G85yMGn3dSjFFXhjtnUIjd8/7WNOMFWkAEYurcu+nbwo+vp0X9ShRf5cRIWwqwII9zPw 0WqGh0i6lG2I+O+8gurts7gPOSCpmGJrQM91V3fCQfNX56P23PxKyxuWzZ4jKqRGPtAL fFCg==
X-Gm-Message-State: APjAAAUkskBLEEX8OipU5lamgCKHJICywa1Y/HzT3PiNutGdBoH7U0eU E1Db9OQ0v9nt1/OYRWugKUV0mRSSPC4qgnod0Ps=
X-Google-Smtp-Source: APXvYqzCmAy0W0U+ij3/Y2iBtNEw6K8wOHwjB5vMetfAOy/7jjCNDhUyqOJiIaVrlqxYckTX90ktYRlLbF4CUn1+zAA=
X-Received: by 2002:a9d:4a3:: with SMTP id 32mr8166155otm.37.1565970162163; Fri, 16 Aug 2019 08:42:42 -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>
In-Reply-To: <CANMZLAat4X+Eh+fgTrbikO6dusvcvvUr5foj=3OEnbRhQtOHSw@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Fri, 16 Aug 2019 11:42:32 -0400
Message-ID: <CAMm+Lwi9QsW=QXc0fK=u-+PfM7fOhCyX2FugPfqPzghiwHAFcA@mail.gmail.com>
Subject: Re: [irtf-discuss] Why do we need to go with 128 bits address space ?
To: Brian Carpenter <brian.e.carpenter@gmail.com>
Cc: Roland Bless <roland.bless@kit.edu>, irtf-discuss@irtf.org, 6man@ietf.org, IETF discussion list <ietf@ietf.org>, shyam bandyopadhyay <shyamb66@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000003ea83705903dd7df"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/RiyjRuv6KjGbWuxnL6CClPpGk9g>
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 15:42:46 -0000

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.