From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id C7FDD3CB39 for ; Fri, 8 Dec 2023 03:37:38 -0500 (EST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 3B88bbVq023869 for ; Fri, 8 Dec 2023 09:37:37 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7B500201BCA for ; Fri, 8 Dec 2023 09:37:37 +0100 (CET) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 72962201B02 for ; Fri, 8 Dec 2023 09:37:37 +0100 (CET) Received: from [10.11.240.130] ([10.11.240.130]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 3B88bbwJ019270 for ; Fri, 8 Dec 2023 09:37:37 +0100 Message-ID: Date: Fri, 8 Dec 2023 09:37:37 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: fr To: starlink@lists.bufferbloat.net References: <361ee9d0d01da491a6e2b132317d170b@ausics.net> <75790520d6c8d35beb7248f5f5dff952@ausics.net> <924492fc-6ce4-4e62-82d9-c8f0b50ee96d@gmail.com> <8a807397-edef-4dcc-bfa6-f9c1598cbc77@gmail.com> From: Alexandre Petrescu In-Reply-To: <8a807397-edef-4dcc-bfa6-f9c1598cbc77@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CEA-Virus: SOPHOS_SAVI_ERROR_OLD_VIRUS_DATA Subject: Re: [Starlink] Info on IP country ranges 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: Fri, 08 Dec 2023 08:37:39 -0000 Le 08/12/2023 à 09:30, Alexandre Petrescu via Starlink a écrit : > > Le 08/12/2023 à 06:57, Freddie Cash a écrit : >> Dishy gets a /64 > > IF Dishy gets a /64 from the starlink operator then I am afraid one > cant make subnets in home, because each other subnet needs a distinct > /64. > > >> and I've tested DHCPv6 on both my Firewalla and my USG. They do >> prefix delegation to distribute that as a /56 locally. > > I am afraid it is not possible to make a /56 out of a /64 (the inverse > is true). For clarification: there could be a way to make a /56 out of a /128 out of that /64.  The way to do that is to do tunnelling - a third party router would use a tunnelling gateway outside the starlink domain.  But tunnelling means addition of latency.  That would not be an incentive. Alex > > Alex > >> >> No NAT required for IPv6 (incoming or outgoing) connections. And >> there doesn't appear to be any restrictions on IPv6 traffic. >> >> This is with the round Dishy. >> >> Cheers, >> Freddie >> >> Typos due to smartphone keyboard. >> >> On Thu, Dec 7, 2023, 3:54 a.m. Alexandre Petrescu via Starlink >> wrote: >> >> >>     Le 04/12/2023 à 19:17, J Pan via Starlink a écrit : >>     > yes, starlink does respond to its customers' complaints, although >>     > sometimes slowly. its ipv4 address acquisition is scattered >>     around as >>     > a latecomer to the isp world, and as a global local isp, it's more >>     > troublesome. ip packets have to be tunneled back to its home pop >>     where >>     > nat and other functions happen, sometimes around the world, >>     causing a >>     > much higher minimum rtt fluctuation in 15-second handover >>     > intervals---bad for network protocols and applications. ipv6 >> can do >>     > better but currently follows the same route as ipv4---an >>     incentive to >>     > promote ipv6 ;-) >> >>     Excellent incentive! >> >>     It would be good to know whether the dishy router obtains a /56 or >>     a /64 >>     prefix from the starlink ISP.  That is easy to find out by just >>     looking >>     at the packets.  This would tell whether a NAT can be avoided at >>     home, >>     and hence more apps made possible. >> >>     IT would also be good to  know whether the claimed IPv6 access on >>     dishy >>     is via a tunnel (IPv6 in IPv6, or IPv6 in IPv4) or it is 'native' >> (no >>     tunnel).  That will tell many things about additional latency that >>     might >>     be brought in by IPv6.  (we'd want less latency, not more). >> >>     After that, one can look more at promoting IPv6.  Otherwise, IPv6 >>     might >>     still look as a hurdle, an obstacle, additional work that is too >>     little >>     necessary, or might even be worse than IPv4. >> >>     Alex >> >>     > -- >>     > J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, >>     Web.UVic.CA/~pan >>     > >>     > On Mon, Dec 4, 2023 at 4:04 AM Noel Butler >>     wrote: >>     >> Thanks, it seems they are trying it on then :) >>     >> >>     >> On 04/12/2023 10:44, J Pan wrote: >>     >> >>     >> starlink advertises its customer ip address location at >>     >> http://geoip.starlinkisp.net (not always updated but good >> enough in >>     >> most cases and traceroute can confirm to some extent as well) >>     >> -- >>     >> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, >>     Web.UVic.CA/~pan >>     >> >>     >> On Sun, Dec 3, 2023 at 4:15 PM Noel Butler via Starlink >>     >> wrote: >>     >> >>     >> >>     >> I run an open access usenet server, but only for those within >>     my CC, so access is by IP based on our CC allocations from APNIC. >>     >> >>     >> Because IPv4 exhaustion this changes sometimes with buying >>     allocations from other regions, and if they get denied access I >>     encourage them to let us know so we can keep ACL's updated, I've >>     had a request from a starlink user who claims they are here, but >>     traceroute shows them in .DE >>     >> >>     >> tracing some 217.foo.ad.dr >>     >> >>     >> ... >>     >> 9 ae-6.r21.frnkge13.de.bb.gin.ntt.net >>     (129.250.3.183) >>     290.223 ms 290.180 ms ae-1.r20.frnkge13.de.bb.gin.ntt.net >>     (129.250.7.35) >> 280.523 ms >>     >> 10 ae-1.a03.frnkge13.de.bb.gin.ntt.net >>     (129.250.3.152) >>     290.109 ms 289.667 ms 292.864 ms >>     >> 11 ae-0.spacex.frnkge13.de.bb.gin.ntt.net >>     (213.198.72.19) >>     279.611 ms 278.840 ms 279.592 ms >>     >> 12 undefined.hostname.localhost (206.224.65.189) 280.127 ms >>     278.506 ms 284.265 ms >>     >> 13 undefined.hostname.localhost (206.224.65.209) 284.198 ms >>     undefined.hostname.localhost (206.224.65.201) 274.663 ms 273.073 ms >>     >> 14 * * * >>     >> >>     >> >>     >> As it is our policy to not collect any user info or issue >>     user/pass's and  only allow access by IP, I'm hoping someone here >>     knows if they are full of it, or does starlink really assign >>     addresses from anywhere? That one hardly makes sense for user >>     experience, or maybe starlink has so few users in this country >>     they haven't bothered changing anything yet? >>     >> >>     >> -- >>     >> >>     >> Regards, >>     >> Noel Butler >>     >> >>     >> >>     >> _______________________________________________ >>     >> Starlink mailing list >>     >> Starlink@lists.bufferbloat.net >>     >> https://lists.bufferbloat.net/listinfo/starlink >>     >> >>     >> >>     >> -- >>     >> >>     >> Regards, >>     >> Noel Butler >>     >> >>     >> >>     > _______________________________________________ >>     > Starlink mailing list >>     > Starlink@lists.bufferbloat.net >>     > https://lists.bufferbloat.net/listinfo/starlink >>     _______________________________________________ >>     Starlink mailing list >>     Starlink@lists.bufferbloat.net >>     https://lists.bufferbloat.net/listinfo/starlink >> > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink