[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