[Starlink] Info on IP country ranges

[David Fernández]

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? 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