From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id E4CA93CB37 for ; Thu, 4 Nov 2021 15:11:01 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 159B1187B1; Thu, 4 Nov 2021 15:12:38 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 3eYe6nX299zt; Thu, 4 Nov 2021 15:12:36 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 7ADB41805B; Thu, 4 Nov 2021 15:12:36 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 31CF27B; Thu, 4 Nov 2021 15:10:59 -0400 (EDT) From: Michael Richardson To: Dave Taht , Darrell Budic , starlink@lists.bufferbloat.net In-Reply-To: References: <7907F9D1-9511-4254-BD8F-701888EB6778@onholyground.com> <172619.1636049781@dooku> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Subject: Re: [Starlink] Starlink tidbits from NANOG X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2021 19:11:02 -0000 <#secure method=pgpmime mode=sign> >> Even if they used IPv6 for the "last mile" and ran NAT64, that would still be >> a major improvement over trying to run dual stack. That's what the smarter >> mobile operators are already doing. (jio, some US carriers...) > have these operators have solved the mobility problem ipv6 has always > had? If you are speaking about the issue that Enterprises have that they'd like to continue to run their internal network when changing ISPs (using NAT44 at the edge), then the answer is that mostly, it's a problem caused by IPv4-think. (The fact that public /48s are not yet free is also an issue) I don't expect that Starlink will have this problem, and in the home, the ULAs generated by 7204 compliant CPE devices solves most issues. (We still have a source address selection problem: but that problem won't go away until a few dozen core Google/Microsoft/Apple developers are forced to live in an IPv6-only home network.) And JIO (India) and other LTE operators' deal mostly with handsets, which don't have permanently up internal networks (alas). > if not then I tend towards a custom l2 that supports anything on top > of it, which might > even include cool things like icn. More L2 tricks will not save the day. It just makes the network invisible and thus undebuggable. It's time to acknowledge that ethernet is not a fat Yellow COAX. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [