[Starlink] Info on IP country ranges

Marc Blanchet marc.blanchet at viagenie.ca
Wed Dec 13 17:59:02 EST 2023 


> Le 13 déc. 2023 à 17:57, Marc Blanchet <marc.blanchet at viagenie.ca> a écrit :
> 
> 
> 
>> 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
> 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.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/6436ae06/attachment-0001.html>

More information about the Starlink mailing list