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 D145E3CB39 for ; Fri, 8 Dec 2023 05:22:47 -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 3B8AMj49023879; Fri, 8 Dec 2023 11:22:45 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9301C20350F; Fri, 8 Dec 2023 11:22:45 +0100 (CET) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 83FD320345A; Fri, 8 Dec 2023 11:22:45 +0100 (CET) Received: from [10.8.32.70] (is156570.intra.cea.fr [10.8.32.70]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 3B8AMji9049505; Fri, 8 Dec 2023 11:22:45 +0100 Message-ID: <69da68cf-8746-45f8-9537-8fd8252de115@gmail.com> Date: Fri, 8 Dec 2023 11:22:44 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: fr To: Steven , Freddie Cash Cc: 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: 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 10:22:48 -0000 Le 08/12/2023 à 09:40, Steven a écrit : > You do indeed get a /56, so are able to assign unique /64s to each of your networks. Do you get that /56 from starlink or from somebody else? If you use a non-starlink router, it might be that the IPv6 feature of that non-starlink router gets that /56  from the outside of starlink domain. > > Your router obtains an address using SLAAC for your WAN interface from a /64 (not sure if this /64 is unique to each customer or shared). Ok, good to know. > > You can then request a /56 using DHCP-PD (separate to the /64 used on the WAN interface). Yes, it might be indeed that the router (provided by starlink router, or not by somebody else) runs a DHCPv6-PD server. Alex > > Cheers, > Steven > > On Fri, 8 Dec 2023, at 7:30 PM, Alexandre Petrescu via Starlink wrote: >> 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). >> >> 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