I use "mosh" instead of ssh. It stays nailed up no matter what you do. It is almost a religious experience to shut down your state on a laptop, go to a coffee shop, and have everything "still there".
The only major flaw in mosh is that it does not support scrollback. On Sat, Jan 6, 2024 at 9:59 AM Alexandre Petrescu via Starlink <starlink@lists.bufferbloat.net> wrote: > > > > Le 24/12/2023 à 02:29, Lukasz Bromirski via Starlink a écrit : > > > > Maybe it's easier/better to "simply" use SSH over SCTP if keeping > > connection up while changing local gateway IP is requirement? > > I think it is a good idea. The ssh ability is probably the primary > necessity in almost all computer-related works. A stable ssh connection > will help anything else make work. > > SSH over SCTP (simultaneous), or even over simple TCP, will resist and > come back up when the IP address changes, be that the IP address of > intermediaries or of the host computer. With SCTP, probably, will come > back faster, and maybe offer higher bandwidth. > > SSH over QUIC might work even better. > > But there can be more to it than that. > > There are other applications than ssh, which might not be able to take > advantage of TCP's ability to restart, SCTP's simultaneous paths, or > QUIC's other advantages. Because they dont run on UDP or on other > transport layers. > > To make these non-ssh non-TCP/QUIC resist the changes of IP addresses > they involve various mechanisms of restarting the app, buffering, and more. > > One just has to make sure that the IP addresses of the ends, and the > intermediary paths, stay up. In in this respect starlink (as all ISPs) > should strive to keep IP address stable for end users, and the IP paths up. > > Alex > > > > > -- > > ./ > > > >> On 13 Dec 2023, at 23:57, Marc Blanchet via Starlink > >> <starlink@lists.bufferbloat.net> wrote: > >> > >> > >> > >>> 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: > >> <quicssh.png> > >> moul/quicssh: SSH over QUIC <https://github.com/moul/quicssh> > >> github.com <https://github.com/moul/quicssh> > >> > >> <https://github.com/moul/quicssh> > >> > >> 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 <mailto:Starlink@lists.bufferbloat.net> > >> https://lists.bufferbloat.net/listinfo/starlink > >> <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 -- 40 years of net history, a couple songs: https://www.youtube.com/watch?v=D9RGX6QFm5E Dave Täht CSO, LibreQos _______________________________________________ Starlink mailing list Starlink@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/starlink
