From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 BFF723CB41 for ; Tue, 12 Dec 2023 05:52:19 -0500 (EST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 3BCAqIlF047150; Tue, 12 Dec 2023 11:52:18 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id F3D2E204809; Tue, 12 Dec 2023 11:52:17 +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 E432E202C69; Tue, 12 Dec 2023 11:52:17 +0100 (CET) Received: from [10.14.129.252] ([10.14.129.252]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 3BCAqHLC055852; Tue, 12 Dec 2023 11:52:17 +0100 Message-ID: <5e5c9075-c1e2-4946-951b-82068aa386d5@gmail.com> Date: Tue, 12 Dec 2023 11:52:17 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: fr To: Steven , J Pan Cc: starlink@lists.bufferbloat.net References: <361ee9d0d01da491a6e2b132317d170b@ausics.net> <924492fc-6ce4-4e62-82d9-c8f0b50ee96d@gmail.com> <8a807397-edef-4dcc-bfa6-f9c1598cbc77@gmail.com> <69da68cf-8746-45f8-9537-8fd8252de115@gmail.com> <7a20ea4f-4f16-4584-9f53-1ee3c72afd6f@app.fastmail.com> <26abce66-300f-405e-ad18-cc32695580fa@gmail.com> <4d0cd8c6-9de7-4976-8d46-ef159ea06c58@gmail.com> <21b2df7e-23c6-4c84-980f-635f41483c29@app.fastmail.com> <19c3c701-7c1a-4f04-a35f-bbec3055a54b@app.fastmail.com> <9d67c201-e759-4730-aa0c-e1c1a7186f84@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: Tue, 12 Dec 2023 10:52:19 -0000 Le 12/12/2023 à 11:33, Steven a écrit : > Hi Alex, > > Thank you for the further detail, my apologies if I misunderstand your line of inquiry. I had interpreted it to mean that you were still not convinced it was native from the perspective of the end-user visible components. > > You are right that there may be some IPv6-in-IPv4 encapsulation occurring within the Starlink network that is undetectable to end-users. That said I would be surprised if that was the case but as you highlight can't say conclusively, not having inside knowledge as to their architecture. > > If it helps, the latency and throughput I have measured of IPv4 vs IPv6 on Starlink is comparable, so if encapsulation is occurring it doesn't appear to be having a noticeable performance impact. It is great that IPv6 latency on starlink is comparable to that of IPv4. Alex > > Regards, > Steven > > On Tue, 12 Dec 2023, at 9:22 PM, Alexandre Petrescu wrote: >> Le 12/12/2023 à 03:43, Steven a écrit : >>> Thanks for this reference that explicitly states it is IPv6 native. >>> >>> https://support.starlink.com/?topic=1192f3ef-2a17-31d9-261a-a59d215629f4 is another Starlink resource that confirms that a /56 is provided. This one doesn't explicitly mention native, but as mentioned I am confident it is. >> Thanks for the pointer.  It clarifies indeed almost all my questions >> about IPv6 to starlink end users.  It is clear about that /56 to end >> users.  You also provided confirmation that is with DHCPv6-PD, and not >> tunnelbroker nor 6to4.  This is already very good. >> >> What I further asked (is IPv6 encapsulated in IPv4?) might probably not >> be within the reach of non-starlink administrators, not visible to >> starlink end users.  Sorry for having given the impression that I might >> doubt the skilfullness. >> >> For example, in 3GPP networks, it is also said, and generally agreed by >> very skilled persons, that almost all IPv6 is provided as native IPv6. >> In that context, it means that the packets from smartphone to a core >> network entity are not encapsulated in IPv4. But, it is also agreed that >> within that core network, that IPv6 is encapsulated in the GTP protocol, >> which is an UDP/IPv4 protocol. This encapsulation of IPv6 in IPv4 is >> invisible to end users, even if the encapsulation is there. >> >> For 3GPP, the use of GTP is very much dedicated to supporting mobility - >> a user keeps a same IP address while changing base stations and S-GWs or >> SGSNs.  In starlink, on the contrary, it is probably not the case that >> the GTP protocol is used for mobility (I dont know?), because starlink >> says that the IP address might change during mobility (that URL you >> point to says "Our system is dynamic where moving the Starlink to >> another location [...] may cause the public IP to change."); so maybe >> IPv6 is not encapped in UDPv4.  Still, another role of GTP in 3GPP is >> that of providing a notion of 'circuit', for needs such as AAA: one such >> 'circuit' is associated to one authenticated and billed user.  And >> starlink users _are_ authenticated and billed, too.  Thus, one might >> wonder what other than 3GPP's GTP protocol is starlink using to provide >> that notion of 'circuit'-per-user.  Maybe that starlink-circuit protocol >> is using tunnels, and that tunnel might be an IPv4 tunnel; it might also >> be an IPv6 tunnel.  Maybe it is using MPLS. Maybe something else. >> >> It is  worth considering about standards work, interoperability with >> others, a probable NTN-TN convergence, and similar. >> >> Alex >> >>> Cheers, >>> Steven >>> >>> On Tue, 12 Dec 2023, at 1:29 PM, J Pan wrote: >>>> yes. https://starlink-enterprise-guide.readme.io/docs/ip-addresses >>>> "Starlink is IPv6 native network. Using IPv6 is more flexible and >>>> future-proof." starlink has greatly improved tech docs >>>> -- >>>> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan >>>> >>>> On Mon, Dec 11, 2023 at 5:10 PM Steven Honson via Starlink >>>> wrote: >>>>> Hi Alex, >>>>> >>>>> As an experienced network engineer with extensive experience with IPv6, I'm confident this is native IPv6. >>>>> >>>>> Cheers, >>>>> Steven >>>>> >>>>> On Tue, 12 Dec 2023, at 2:30 AM, Alexandre Petrescu wrote: >>>>>> Steven, >>>>>> >>>>>> Thanks for the clarifications. It is indeed very advantageous to use >>>>>> DHCPv6-PD from a Client in home to starlink Server, and obtain a /56. >>>>>> >>>>>> But to be native IPv6, it would need the IPv6 packets to travel natively >>>>>> (sit directly on the link layer) between home and starlink network. If >>>>>> these IPv6 packets are encapsulate in IPv4, then there would be a risk >>>>>> of additional latency compared to v4. >>>>>> >>>>>> A possible way to find out whether it's IPv6 native (and hence no >>>>>> additional latency) is to browse speedtest.net from an IPv4-only client >>>>>> vs from an IPv6-only client. An IPv6-only Windows client can be made by >>>>>> unchecking the IPv4 box in interface Properties window. >>>>>> >>>>>> Ideally, if it is IPv6 native, the latency reported by speedtest.net is >>>>>> approximatively the same on IPv4 vs on IPv6 (sometimes the IPv6 latency >>>>>> is even lower than on IPv4). If the latency reported on IPv6 is higher >>>>>> than on IPv4 it could be for many reasons, and one of them could be that >>>>>> IPv6 is not native, but encapsulated in IPv4. The IPv4 encapsulating >>>>>> endpoint could be on Dishy. >>>>>> >>>>>> Alex >>>>>> >>>>>> Le 08/12/2023 à 13:24, Steven a écrit : >>>>>>> Alexandre, >>>>>>> >>>>>>>> Are you sure the DHCPv6-PD server is in Starlink network and not on the >>>>>>>> MikroTik router? >>>>>>> That would be quite the unusual setup, and even so would require that I obtain said /56 from elsewhere (such as via a tunnel) to then delegate back to myself... >>>>>>> >>>>>>>> It could be that the MikroTik router runs tunnelbroker, obtains a /56 >>>>>>>> from HE, splits that /56 into multiple /64s and puts it on the DHCPv6-PD >>>>>>>> local server config files. >>>>>>> I am confident this is not the case since I configured these routers from scratch. >>>>>>> >>>>>>>> It could also be that the DHCPv6-PD server is run on the Dishy. >>>>>>> It is unlikely that it is on the Dishy, as the latency to the DHCPv6 servers IP address, as well as the first IP hop, indicates the usual Ground->Space->Ground latency I'd expect. >>>>>>> >>>>>>>> It could also be that the DHCPv6-PD server is run on the starlink ground >>>>>>>> network: maybe on the teleport, maybe deeper on the starlink network. >>>>>>> Yes, this is the most likely place they are running this, likely the PoP you are being routed through. >>>>>>> >>>>>>>> Do you know the IPv6 address of your DHCPv6-PD Server? >>>>>>> The DHCPv6 server address is a Starlink IPv6 address, the same one as my default gateway (`2406:2d40:xxx:xxx::1`). The /56 I am being allocated is also from the same /32 as this DHCPv6 server, with the /32 being 2406:2d40::/32, which you'll note is allocated to Starlink. >>>>>>> >>>>>>> Cheers, >>>>>>> Steven >>>>> _______________________________________________ >>>>> Starlink mailing list >>>>> Starlink@lists.bufferbloat.net >>>>> https://lists.bufferbloat.net/listinfo/starlink