> Le 13 déc. 2023 à 17:57, Marc Blanchet <marc.blanc...@viagenie.ca> a écrit : > > > >> 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 > 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.
I should add that someone wrote a draft on SSH over QUIC natively (draft-bider-ssh-quic) but seems dead and no implementation known Marc. > > 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
