Re: [Starlink] Info on IP country ranges

[Alexandre Petrescu <alexandre.petrescu@gmail.com>]

Le 12/12/2023 à 11:33, Steven a écrit :
> 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.
>
> 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.

It is great that IPv6 latency on starlink is comparable to that of IPv4.

Alex

>
> 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@UVic.CA, Web.UVic.CA/~pan
>>>>
>>>> On Mon, Dec 11, 2023 at 5:10 PM Steven Honson via Starlink
>>>> <starlink@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@lists.bufferbloat.net
>>>>> https://lists.bufferbloat.net/listinfo/starlink