> Le 13 déc. 2023 à 15:58, David Fernández via Starlink > <starlink@lists.bufferbloat.net> a écrit : > > Hi, > > About this: > "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." > > What is that way?
Well, that was a side note, not really related to the subject of this mailing list, but since you ask, it is using a quic proxy; see: https://github.com/moul/quicssh moul/quicssh: SSH over QUIC github.com There is also carrying generic IP trafic over a QUIC tunnel (see the IETF masque wg), but since SSH is over TCP, not great to have two transport protocols one over the other. Marc. > Can you point to an explanation? Thank you! > > Regards, > > David > > >> Date: Wed, 13 Dec 2023 09:37:40 -0500 >> From: Marc Blanchet <marc.blanc...@viagenie.ca> >> To: Alexandre Petrescu <alexandre.petre...@gmail.com> >> Cc: Sebastian Moeller <moell...@gmx.de>, Steven >> <bufferbloat-li...@steven.honson.au>, starlink@lists.bufferbloat.net >> Subject: Re: [Starlink] Info on IP country ranges >> Message-ID: <1fe6b070-c2a0-4c35-8876-33feded81...@viagenie.ca> >> Content-Type: text/plain; charset=utf-8 >> >> >> >>> 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
