Re: [v6ops] The bottom is /112 (was: RE: Extending a /64) -- How about new fixed bottom /80 win-win for all - epiphany at 6:54am after v6ops preso

Ole Troan <otroan@employees.org> Fri, 20 November 2020 22:41 UTC

Return-Path: <otroan@employees.org>
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 B9AF33A0B04; Fri, 20 Nov 2020 14:41:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 nuwa6d6Oitbl; Fri, 20 Nov 2020 14:41:10 -0800 (PST)
Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81C323A0AFD; Fri, 20 Nov 2020 14:41:10 -0800 (PST)
Received: from [192.168.10.178] (dhcp21719716422.blix.com [217.197.164.22]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id D450E4E11CAB; Fri, 20 Nov 2020 22:41:09 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Ole Troan <otroan@employees.org>
Mime-Version: 1.0 (1.0)
Subject: Re: [v6ops] The bottom is /112 (was: RE: Extending a /64) -- How about new fixed bottom /80 win-win for all - epiphany at 6:54am after v6ops preso
Date: Fri, 20 Nov 2020 23:41:06 +0100
Message-Id: <7E87C304-802E-4B2F-9DDB-687C91C29E21@employees.org>
References: <CABNhwV0TbS7Kiynb=jvczJFDyy=uMfd-he+d0ii7aU5AnsUKeA@mail.gmail.com>
Cc: "Joel M. Halpern" <jmh@joelhalpern.com>, 6MAN <6man@ietf.org>, IPv6 Operations <v6ops@ietf.org>, JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org>
In-Reply-To: <CABNhwV0TbS7Kiynb=jvczJFDyy=uMfd-he+d0ii7aU5AnsUKeA@mail.gmail.com>
To: Gyan Mishra <hayabusagsm@gmail.com>
X-Mailer: iPhone Mail (18B92)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/qSHNDCtAyQpcQKzuDINtiV0GFgw>
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, 20 Nov 2020 22:41:12 -0000


> On 20 Nov 2020, at 23:27, Gyan Mishra <hayabusagsm@gmail.com> wrote:
> 
> The mobile device would receive a shorter prefix let’s say /56 but not know what to do with it since it’s expecting a /64.
> 
> So that a major gap and the only solution is updating RFC 4291 removing the 64 bit boundary allowing for shorter prefix and now as well longer prefixes to work and in that respect now provide the much needed parity with static and DHCPv6 which can do any prefix length.

I am sorry, but I don’t follow how you got to that conclusion. 
Address assignment != prefix delegation. 

In the plethora of emails I have lost track. Would you be able to reiterate the sets of technical problems you desire solved?

Cheers,
Ole