From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 048403B29D for ; Mon, 19 Jul 2021 08:14:58 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id BA2D538997; Mon, 19 Jul 2021 08:18:12 -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 v0_t5gDgx1jJ; Mon, 19 Jul 2021 08:18:08 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 896A83898D; Mon, 19 Jul 2021 08:18:08 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id AB81E5A2; Mon, 19 Jul 2021 08:14:52 -0400 (EDT) From: Michael Richardson To: David Lang , Dave Taht , "starlink\@lists.bufferbloat.net" , "David P. Reed" In-Reply-To: References: <1625856001.74681750@apps.rackspace.com> <15095.1626468660@localhost> 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 and bufferbloat status? 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: Mon, 19 Jul 2021 12:14:59 -0000 --=-=-= Content-Type: text/plain David Lang wrote: mcr> I'm scared that these paths will centrally managed, and not based upon mcr> longest prefix (IPv6) match. david> unless you are going to have stations changing their IPv6 address frequently, dt> I'd really, really, hope for a dedicated /56 per station, no changes, dt> EVER, unless the user requests it it falls under attack. Perhaps two dt> /56s for failover reasons. Really silly dt> to make ipv6 dynamic in this environment. david> if you are going to route based on IPv6 prefixes, then the david> prefixes need to have a close relationship to location (which is david> what routing needs to care about). If you have fixed addresses and david> mobile stations, you can't route based on address prefixes. Well, you could go all way to https://datatracker.ietf.org/doc/html/draft-hain-ipv6-geo-addr-02 This makes most sense if you then have SHIM6 (being revised soon), and/or MPTCP to move from this overlay network to the transport network. > One of the wonderful things about the Internet is that no device needs to > understand the entire network. They just need information about which next > hop to use to get to different destiantions. This is a really important thing to remember. RFC6550 adds the RFC6553 header to deal with some kinds of loops. RFC6550 (RPL) might work well among satellites, or maybe not. One would have a multitude of DODAGs, but if they are non-storing DODAGs, then that doesn't mean that every satellite has any state. I would run a DODAG of exit nodes, and run user traffic as an overlay. -- ] 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 [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmD1bLwACgkQgItw+93Q 3WUvIQf/Ti5kXixwzpo9ZqNaiMPRDMCapJ7Uw+oGUjnb/KoJWuIURKP6Xpsi8V4Y cdqwX/5jjxWM7+ZoMrbsUUIIOgQE3JHeH6+kxCbxlHREGW0gnj5gIsIDvUrCmc4Y anU2AHY+92K58dA7wONvyV8VSCZuqxral+ICkvBwBXY08HppEURNecEJQHSOS92Q ozmPYkFilhv0eYSPVQ6EPoKgG6NPoAtr/4WLJo/c60PQT+Wj2r26s5E9IGXTV9OT gpMsAQQqG7E7EVfNmExcAgJxFxVjlr09iQa3EahNZuQxUERjujLoK4NNG7AwFhDj iswESPWn6+ENFfMIOfdxT1AMi/gS8Q== =PNII -----END PGP SIGNATURE----- --=-=-=--