> Le 13 déc. 2023 à 05:33, Alexandre Petrescu via Starlink > <starlink@lists.bufferbloat.net> a écrit : > > > Le 12/12/2023 à 11:50, Sebastian Moeller a écrit : >> Hi Steven, >> >> >> >>> On Dec 12, 2023, at 11:33, Steven via Starlink >>> <starlink@lists.bufferbloat.net> wrote: >>> >>> 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. >> One easy thing to check would be MTU/MSS to arbitrary internet end >> points, as any encapsulation typically takes up some space and not every >> operator id courteous enough to enlarge the tunnel MTU such that the inner >> internet visible effective MTU is 1500 bytes. Sure, not a guarantee but at >> least an easy to check hint. >> >>> 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. >> Or both IPv6 and Iv4 user packets go through the same type of tunnel >> set-up to get to their home-base station? > > Indeed, if tunnelling is used within the starlink network (like GTP a 3GPP > network) that would presumably encapsulate both IPv4 and IPv6. A tunnel > elimination technique within the starlink network would presumably reduce the > latency both of IPv4 user packets and of IPv6 user packets. > > There is also the mobility aspect of the tunnels. > > A tunnel within 3GPP network (GTP) is used, among other reasons, to support > mobility. The 'mobility', among some interpretations, is to maintain a > constant IP address for a moving end user. > > Surprisingly, the URL > https://support.starlink.com/?topic=1192f3ef-2a17-31d9-261a-a59d215629f4 > explains that that kind of mobility is not supported in starlink, i.e. the > end user might get another IP address if going to some other area. It is > surprising in that in other starlink.com URLs they offer starlink service for > automobiles, and these typically move a lot. Maybe the starlink-connected > automobiles do change their IP addresses a lot, but the end users dont care > that much. > > To support mobility within a starlink network - maintain constant all IP > addresses in a car - maybe one would try the DHCPv6 CONFIRM message to try to > maintain the same allocated /56 but it another area. Maybe the starlink > DHCPv6-PD server will satisfy that CONFIRM, or maybe not.
I would be very (happily) surprised if they do support that. > > Or maybe there is a need of some other protocol in starlink, or in user > equipment connected to starlink (Dishy, third party router), to offer that > mobility. But without adding new latency, of course. > > (this mobility aspect is on topic of the IP country ranges - cross-border > areas would ideally not break connectivity). That problem (IP address stability to keep connection going) is fading away, because the QUIC transport does re-establish connections for you automatically. So as every day passes that QUIC is getting more and more deployed and used (now counting for >30% of traffic), that mobility problem goes away. Yes, not all protocols have been carried over to QUIC, but it is in the process for many. There is even a way to do standard ssh (aka over TCP) over QUIC (a bit clunky but works) to keep the ssh connection going while changing IP addresses. Marc. > > Alex > >> >> Regards >> Sebastian >> >> P.S.: All wild speculation, feel free to ignore ;) >> >> >>> 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), p...@uvic.ca, >>>>>> Web.UVic.CA/~pan >>>>>> >>>>>> On Mon, Dec 11, 2023 at 5:10 PM Steven Honson via Starlink >>>>>> <starlink@lists.bufferbloat.net> 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 >>> _______________________________________________ >>> 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
