[Starlink] Info on IP country ranges

Sebastian Moeller moeller0 at gmx.de
Mon Jan 8 05:54:26 EST 2024


> On Jan 6, 2024, at 16:06, Dave Taht via Starlink <starlink at lists.bufferbloat.net> wrote:
> 
> 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.

	+1 for mosh. I tend to also use screen so I can have terminal sessions that I can re-attach to later...




> 
> 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
> _______________________________________________
> Starlink mailing list
> Starlink at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink



More information about the Starlink mailing list