Re: [EXTERNAL] Re: I-D Action: draft-mishra-6man-variable-slaac-01.txt

Fernando Gont <fernando@gont.com.ar> Fri, 06 November 2020 09:58 UTC

Return-Path: <fernando@gont.com.ar>
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 74A3F3A101C for <ipv6@ietfa.amsl.com>; Fri, 6 Nov 2020 01:58:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.135
X-Spam-Level:
X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.247, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, 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 cOXv6LItWKqY for <ipv6@ietfa.amsl.com>; Fri, 6 Nov 2020 01:58:20 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F32C13A101B for <ipv6@ietf.org>; Fri, 6 Nov 2020 01:58:18 -0800 (PST)
Received: from [IPv6:2800:810:464:b9c:988a:bf3:67ea:9b60] (unknown [IPv6:2800:810:464:b9c:988a:bf3:67ea:9b60]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 69B61280599; Fri, 6 Nov 2020 09:58:15 +0000 (UTC)
Subject: Re: [EXTERNAL] Re: I-D Action: draft-mishra-6man-variable-slaac-01.txt
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>, IPv6 List <ipv6@ietf.org>
References: <160409741426.1448.16934303750885888002@ietfa.amsl.com> <3c1c3ab5-5726-b141-e7ed-618984bbbdb1@gmail.com> <CABNhwV1zoZpZNjb54rEys4+49H3vpebZW2g9JbO1_58eR+WnQg@mail.gmail.com> <CAKD1Yr0vvyQnTGRoSh4qa4He1gq5HXXRaKU3pVLtCtDUzcwL_w@mail.gmail.com> <CAD6AjGQPatbg5=OaMzxJXy5mGZai1bqLfg8f+9SUnfg=s1kADg@mail.gmail.com> <e55a9fbf-a93c-a96f-7991-f0c3aad8ce16@gmail.com> <CAD6AjGSTQjKQuY1+0DNm5NRgTRkWUQ=eRhnvyKCXvKc3Kvy9TQ@mail.gmail.com> <CAKD1Yr3h_Jypxx49-e-PUFvtX0y7DaXf-XvBgK4-oQAjEe8vvA@mail.gmail.com> <23631B74-1870-4F53-9CC1-F884505E61D8@gmail.com> <b9670467-b89b-27b4-4dbc-08c91fc7e74e@cea.fr> <2d4ceb2a759c49b6823e536b31d5e3e0@boeing.com> <4b7359b2ff2f48f79eef4c10c395c8e6@huawei.com>
From: Fernando Gont <fernando@gont.com.ar>
Message-ID: <f11ec469-42c3-b78c-d7f2-869645c5dc64@gont.com.ar>
Date: Fri, 06 Nov 2020 06:55:00 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <4b7359b2ff2f48f79eef4c10c395c8e6@huawei.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/OjRq8uKDsXssO-3aeb1M2tgouxI>
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, 06 Nov 2020 09:58:24 -0000

On 6/11/20 06:27, Vasilenko Eduard wrote:
> Hi all,
> You are discussing here the very big and principal question indeed.
> IPv6 has been designed with 64bit address space. Other 64bits have been abused for L2 address inserted into L3 address.
> It could potentially has some advantages and disadvantages.
> Example for potential advantage: Address Resolution Protocol (ND) is not needed.

This is not correct, since the IID has always allowed for manual 
configuration -- hence you cannot assume that what's in the IID is the 
underlying MAC address.  -- And, at the time of this writing, your best 
bet is that it isn't (think RFC7217, RFC4941, and manual configuration).



> Example of potential disadvantage: almost half of L3 address bits are wasted (a few bits are needed inside the link).

I wouldn't necessarily say "wasted"... but yeah, I see what you mean.



> I personally do not see how advantages have been leveraged and disadvantages mitigated. Hence, the request to expand address space above 64bit looks valid.
> But the opposite argument that "64bit is enough address space for mankind in the next century" is the valid too.

I don't know what  "expanding the address space" would mean. If the 
argument is "be able to do SLAAC with != 64", then I'd probably agree, 
though. -- and my understanding is that disagreement on this point is 
why rfc4941bis was stalled.

Thanks,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1