[Starlink] Info on IP country ranges

Marc Blanchet marc.blanchet at viagenie.ca
Wed Dec 13 17:57:08 EST 2023 


> 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:
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.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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20231213/47d9c127/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: quicssh.png
Type: image/png
Size: 85430 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20231213/47d9c127/attachment-0001.png>

More information about the Starlink mailing list