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

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Fri, 16 August 2019 21:49 UTC

Return-Path: <mohta@necom830.hpcl.titech.ac.jp>
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 B333212007C for <ipv6@ietfa.amsl.com>; Fri, 16 Aug 2019 14:49:53 -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 IrGcCy7MT7XB for <ipv6@ietfa.amsl.com>; Fri, 16 Aug 2019 14:49:50 -0700 (PDT)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id B52FD120052 for <6man@ietf.org>; Fri, 16 Aug 2019 14:49:50 -0700 (PDT)
Received: (qmail 31796 invoked from network); 16 Aug 2019 21:37:48 -0000
Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 16 Aug 2019 21:37:48 -0000
Subject: Re: [irtf-discuss] Why do we need to go with 128 bits address space ?
To: IETF discussion list <ietf@ietf.org>
Cc: irtf-discuss@irtf.org, 6man@ietf.org, shyam bandyopadhyay <shyamb66@gmail.com>
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>
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-ID: <b0543025-f6c4-6703-11a0-2958478f47e3@necom830.hpcl.titech.ac.jp>
Date: Sat, 17 Aug 2019 06:49:50 +0900
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <CAMm+Lwi9QsW=QXc0fK=u-+PfM7fOhCyX2FugPfqPzghiwHAFcA@mail.gmail.com>
Content-Type: text/plain; charset="iso-2022-jp"; format="flowed"; delsp="yes"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Ku1K5gEC1iu1n5qScIyZR87-6x0>
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 21:49:54 -0000

Fernando Gont wrote:

 > The specific 128-bit value seems to be a compromise between two
 > proposals
 >  
(https://www.lacnic.net/innovaportal/file/2578/1/ipv6-latnic2018-hinden-01.pdf)...
 > but I won't speak for Bob. ;-)

That is an inappropriate explanation. As variable length address
is not adopted, among three reasons for TUBA on slide 13:

	Compatible with OSI NSAP address plans
	Large enough for auto-configuration using IEEE 802 addresses
	Could start with short addresses and grow later

only

	Large enough for auto-configuration using IEEE 802 addresses

remains.

That is, IPv6 address unnecessarily became 128bit long, merely
because of poor idea of so stateful SLAAC.


Phillip Hallam-Baker wrote:

 >> e) 64 isn't enough to allow lots of bits for topology plus
 >> lots of bits for privacy

is a typical misunderstanding by those who do not know 32 bit
IPv4 address is enough to represent hierarchical topology of
the Internet today.

 >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.

No, the reason is because I pointed out that MAC address of IEEE1394
is already 64bit long. Before that, it was 80+48.

> This hasn't happened because it is nonsense. Disclosing the
> structure of your internal network to potential attackers is stupid.

Wrong.

Extending MAC address 64 bit has nothing to do with internal topology.

							Masataka Ohta