Re: [v6ops] Implementation Status of PREF64

Owen DeLong <owen@delong.com> Thu, 14 October 2021 20:26 UTC

Return-Path: <owen@delong.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF8B73A0CB5 for <v6ops@ietfa.amsl.com>; Thu, 14 Oct 2021 13:26:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=delong.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 nnCSMhFPKVwV for <v6ops@ietfa.amsl.com>; Thu, 14 Oct 2021 13:26:15 -0700 (PDT)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id B418B3A0CAC for <v6ops@ietf.org>; Thu, 14 Oct 2021 13:26:13 -0700 (PDT)
Received: from smtpclient.apple ([IPv6:2620:0:930:0:ed73:98e2:9599:2427]) (authenticated bits=0) by owen.delong.com (8.16.1/8.15.2) with ESMTPSA id 19EJb4qd393314 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 14 Oct 2021 12:37:05 -0700
DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 19EJb4qd393314
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1634240225; bh=uy8XhIyh806KD9SK0ULQsYZW7kXDF7dc4gjqxdOSYAk=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=KfavrzNfHQA7m/1ThOnD9LmdUs20eBpgI6aTsMfh8edxeFNVQCcqbTChMPj74z/D2 TBhQ6t621XHca+6kT12Bf03h5zbkd8cOtMTxyF5gcUhEyYt4Q9EBW8A4BB/avCqH0L sMBX90htnbU14qWV0/ROcAs3FhlmuIsCv6Uzjr2o=
From: Owen DeLong <owen@delong.com>
Message-Id: <CA5E9189-CB94-4362-AE9E-39B857192393@delong.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_95C780E0-DACD-411A-95AB-9B18C744C914"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Thu, 14 Oct 2021 12:37:03 -0700
In-Reply-To: <4577684E-FF06-4C48-B70A-FA832D28BE02@employees.org>
Cc: Ted Lemon <mellon@fugue.com>, "Pascal Thubert (pthubert)" <pthubert=40cisco.com@dmarc.ietf.org>, "v6ops@ietf.org WG" <v6ops@ietf.org>, Owen DeLong <owen=40delong.com@dmarc.ietf.org>
To: Ole Troan <otroan@employees.org>
References: <CAPt1N1=wcJN+ucPR0x7NuG6DYk=Z6zdPEMSSg8L3GkE90-16KA@mail.gmail.com> <4577684E-FF06-4C48-B70A-FA832D28BE02@employees.org>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.4 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Thu, 14 Oct 2021 12:37:05 -0700 (PDT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/RK8qvG7wu97cGSIo-lS1Mkb07yQ>
Subject: Re: [v6ops] Implementation Status of PREF64
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Oct 2021 20:26:22 -0000


> On Oct 14, 2021, at 12:07 , Ole Troan <otroan@employees.org> wrote:
> 
> 
> 
>> On 14 Oct 2021, at 19:11, Ted Lemon <mellon@fugue.com> wrote:
>> 
>> 
>> On Thu, Oct 14, 2021 at 2:56 AM Pascal Thubert (pthubert) <pthubert=40cisco.com@dmarc.ietf.org <mailto:40cisco.com@dmarc.ietf.org>> wrote:
>> A prefix to the host gives Lorenzo the addresses he needs for his devices.  It gives your customers the single state per logical node that they want. It allows to separate what netops manage (down to /64 and direct assignment within) and devops (whatever they do with the longer prefix they get for their node). It does not impose any size for what’s assigned, could be a different thing for each host. It means routing inside the subnet which removes the dreadful broadcast domain.
>> 
>> I see an opportunity for consensus. Can we work that out together and bring a real IPv6 value?
>> 
>> If your proposal is that we use a /64 per host as a way to meet these needs, I agree. This solves everybody's actual problems. There is the issue that some people have expressed a preference for prefixes wider than 64 bits, but this is a preference—there's no technical reason to do this. It's not wrong to have preferences, but it would be nice if we could somehow finally put this discussion to bed.
> 
> Limiting networks that are assigned a /56 to only 256 logical nodes is a non starter. 

Shouldn’t assigning /56s be the non-starter in that question?

Owen