[Starlink] Info on IP country ranges

Sat Jan 6 10:06:14 EST 2024

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 at 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 at lists.bufferbloat.net> wrote:
> >>
> >>
> >>
> >>> Le 13 déc. 2023 à 15:58, David Fernández via Starlink
> >>> <starlink at 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.blanchet at viagenie.ca>
> >>>> To: Alexandre Petrescu <alexandre.petrescu at gmail.com>
> >>>> Cc: Sebastian Moeller <moeller0 at gmx.de>, Steven
> >>>> <bufferbloat-lists at steven.honson.au>, starlink at lists.bufferbloat.net
> >>>> Subject: Re: [Starlink] Info on IP country ranges
> >>>> Message-ID: <1FE6B070-C2A0-4C35-8876-33FEDED81F69 at viagenie.ca>
> >>>> Content-Type: text/plain;charset=utf-8
> >>>>
> >>>>
> >>>>
> >>>>> Le 13 déc. 2023 à 05:33, Alexandre Petrescu via Starlink
> >>>>> <starlink at 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 at 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), Pan at UVic.CA,
> >>>>>>>>>> Web.UVic.CA/~pan
> >>>>>>>>>>
> >>>>>>>>>> On Mon, Dec 11, 2023 at 5:10 PM Steven Honson via Starlink
> >>>>>>>>>> <starlink at 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 at lists.bufferbloat.net
> >>> https://lists.bufferbloat.net/listinfo/starlink
> >>
> >> _______________________________________________
> >> Starlink mailing list
> >> Starlink at lists.bufferbloat.net <mailto:Starlink at lists.bufferbloat.net>
> >> https://lists.bufferbloat.net/listinfo/starlink
> >> <https://lists.bufferbloat.net/listinfo/starlink>
> >
> >
> > _______________________________________________
> > Starlink mailing list
> > Starlink at lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/starlink
> _______________________________________________
> Starlink mailing list
> Starlink at 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