[Starlink] Info on IP country ranges
Alexandre Petrescu
alexandre.petrescu at gmail.com
Fri Dec 8 07:07:11 EST 2023
Steven,
Le 08/12/2023 à 12:54, Steven a écrit :
> Alexandre,
>
> I'm confident it is a Starlink provided /56 for a number of reasons.
A mechanism designed by starlink to achieve this - give /56 to end users
- could be used in other networks too, such as in cellular networks (in
there, only /64s are given).
But I want to be sure about that /56 given by starlink.
>
> 1. I am obtaining the /56 using DHCPv6-PD. A random DHCPv6-PD server out there on the Internet outside of Starlinks network would not be able to receive nor reply to my DHCP requests unless Starlink were actively forwarding this to them.
Are you sure the DHCPv6-PD server is in Starlink network and not on the
MikroTik router?
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.
It could also be that the DHCPv6-PD server is run on the Dishy.
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.
Do you know the IPv6 address of your DHCPv6-PD Server?
> 2. I am not obtaining it using tunneling. I understand these concepts well and am confident there isn't 6to4, a VPN, or any other mechanism at play here.
Ok, I read it.
> 3. The /56 is from a Starlink allocation, as verified by bgp.tools.
I am not familiar with bgp.tools. Maybe one has to loook at that too.
> 4. Numerous others have also obtained a /56 using DHCPv6-PD from Starlink. A quick internet search will yield many others.
Well, thank you for the reporting.
Alex
>
> Regards,
> Steven
>
> On Fri, 8 Dec 2023, at 10:48 PM, Alexandre Petrescu wrote:
>> Steven,
>>
>> Thanks for the reply.
>>
>> Le 08/12/2023 à 11:31, Steven a écrit :
>>> Alex,
>>>
>>> You get that /56 from Starlink.
>>>
>>> I've only seen it done using a non-Starlink router (MiktoTik - see https://github.com/tyd/mikrotik-starlink-ipv6 for example config) in place of the supplied one, with an appropriate PoE injector to power the dish.
>>>
>>> It is definitely a Starlink provided /56, and not obtained via a tunnel or a third party.
>> How do you know the /56 is provided by Starlink and not by somebody else?
>>
>> If it were to me:
>>
>> Quickly, I'd type 'what is my ipv6 address' in google and check whether
>> the first 40 bits of the reported address are equal with the prefix
>> listed for my location at https://geoip.starlinkisp.net/feed.csv
>>
>> For example, if I were in Berlin I'd compare the first 40bits and 42bits
>> of the address reported by google ('what is my...') with each of thsese
>> 40 and 42bits '2a0d:3344:500::/40,DE,DE-BE,Berlin,' ,
>> '2a0d:3344:2400::/42,DE,DE-BE,Berlin,' and
>> '2a0d:3344:1500::/40,DE,DE-BE,Berlin,' reported by that .csv file.
>>
>> The result of that comparison would be a hint (not a decisive answer)
>> easy to obtain of whether the /56 is provided by starlink or not.
>> Because the comparison is only on 40bits (or 42bits) and there could be
>> a /41, or a /43, or larger, routed elsewhere than to starlink, and still
>> match that /56.
>>
>> For more assurance, I would put wireshark on the Ethernet interface of
>> that MikroTik router connected to Dishy; then check whether wireshark
>> reports encapsulated packets, check the dst address of the outer packet,
>> and find the owner of that address in the RIR database (RIPE.net in Europe).
>>
>> For more hints, I'd check the user manual of MikroTik and IPv6. Some
>> URLs about MikroTik and IPv6 tell 'tunnelling', tell 6to4, tell
>> 'tunnelbroker' (HE - Hurricane Electric). The 6to4 is outdated, should
>> not be used. The HE is outside starlink.
>>
>> Of course, maybe I'd try first whether the latency over IPv6 is lower
>> than with IPv4, or equal. (consulting www.speedtest.net can be done via
>> IPv4 or via IPv6). This could tell whether IPv6 is more advantageous
>> than IPv4 from a latency perspective, but there could also be dooubts
>> about where and how are the speedtest servers placed, IPv4 vs IPv6.
>>
>> Alex
>>
>>> I haven't seen this tried using their included router, but would be interested in hearing if DHCP-PD on the LAN segment of the included router yields a prefix delegation too.
>>>
>>> Cheers,
>>> Steven
>>>
>>> On Fri, 8 Dec 2023, at 9:22 PM, Alexandre Petrescu wrote:
>>>> Le 08/12/2023 à 09:40, Steven a écrit :
>>>>> You do indeed get a /56, so are able to assign unique /64s to each of your networks.
>>>> Do you get that /56 from starlink or from somebody else?
>>>>
>>>> If you use a non-starlink router, it might be that the IPv6 feature of
>>>> that non-starlink router gets that /56 from the outside of starlink domain.
>>>>
>>>>> Your router obtains an address using SLAAC for your WAN interface from a /64 (not sure if this /64 is unique to each customer or shared).
>>>> Ok, good to know.
>>>>> You can then request a /56 using DHCP-PD (separate to the /64 used on the WAN interface).
>>>> Yes, it might be indeed that the router (provided by starlink router, or
>>>> not by somebody else) runs a DHCPv6-PD server.
>>>>
>>>> Alex
>>>>
>>>>> Cheers,
>>>>> Steven
>>>>>
>>>>> On Fri, 8 Dec 2023, at 7:30 PM, Alexandre Petrescu via Starlink wrote:
>>>>>> Le 08/12/2023 à 06:57, Freddie Cash a écrit :
>>>>>>> Dishy gets a /64
>>>>>> IF Dishy gets a /64 from the starlink operator then I am afraid one cant
>>>>>> make subnets in home, because each other subnet needs a distinct /64.
>>>>>>
>>>>>>
>>>>>>> and I've tested DHCPv6 on both my Firewalla and my USG. They do prefix
>>>>>>> delegation to distribute that as a /56 locally.
>>>>>> I am afraid it is not possible to make a /56 out of a /64 (the inverse
>>>>>> is true).
>>>>>>
>>>>>> Alex
>>>>>>
>>>>>>> No NAT required for IPv6 (incoming or outgoing) connections. And there
>>>>>>> doesn't appear to be any restrictions on IPv6 traffic.
>>>>>>>
>>>>>>> This is with the round Dishy.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Freddie
>>>>>>>
>>>>>>> Typos due to smartphone keyboard.
>>>>>>>
>>>>>>> On Thu, Dec 7, 2023, 3:54 a.m. Alexandre Petrescu via Starlink
>>>>>>> <starlink at lists.bufferbloat.net> wrote:
>>>>>>>
>>>>>>>
>>>>>>> Le 04/12/2023 à 19:17, J Pan via Starlink a écrit :
>>>>>>> > yes, starlink does respond to its customers' complaints, although
>>>>>>> > sometimes slowly. its ipv4 address acquisition is scattered
>>>>>>> around as
>>>>>>> > a latecomer to the isp world, and as a global local isp, it's more
>>>>>>> > troublesome. ip packets have to be tunneled back to its home pop
>>>>>>> where
>>>>>>> > nat and other functions happen, sometimes around the world,
>>>>>>> causing a
>>>>>>> > much higher minimum rtt fluctuation in 15-second handover
>>>>>>> > intervals---bad for network protocols and applications. ipv6 can do
>>>>>>> > better but currently follows the same route as ipv4---an
>>>>>>> incentive to
>>>>>>> > promote ipv6 ;-)
>>>>>>>
>>>>>>> Excellent incentive!
>>>>>>>
>>>>>>> It would be good to know whether the dishy router obtains a /56 or
>>>>>>> a /64
>>>>>>> prefix from the starlink ISP. That is easy to find out by just
>>>>>>> looking
>>>>>>> at the packets. This would tell whether a NAT can be avoided at
>>>>>>> home,
>>>>>>> and hence more apps made possible.
>>>>>>>
>>>>>>> IT would also be good to know whether the claimed IPv6 access on
>>>>>>> dishy
>>>>>>> is via a tunnel (IPv6 in IPv6, or IPv6 in IPv4) or it is 'native' (no
>>>>>>> tunnel). That will tell many things about additional latency that
>>>>>>> might
>>>>>>> be brought in by IPv6. (we'd want less latency, not more).
>>>>>>>
>>>>>>> After that, one can look more at promoting IPv6. Otherwise, IPv6
>>>>>>> might
>>>>>>> still look as a hurdle, an obstacle, additional work that is too
>>>>>>> little
>>>>>>> necessary, or might even be worse than IPv4.
>>>>>>>
>>>>>>> Alex
>>>>>>>
>>>>>>> > --
>>>>>>> > J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan at UVic.CA,
>>>>>>> Web.UVic.CA/~pan <http://Web.UVic.CA/~pan>
>>>>>>> >
>>>>>>> > On Mon, Dec 4, 2023 at 4:04 AM Noel Butler
>>>>>>> <noel.butler at ausics.net> wrote:
>>>>>>> >> Thanks, it seems they are trying it on then :)
>>>>>>> >>
>>>>>>> >> On 04/12/2023 10:44, J Pan wrote:
>>>>>>> >>
>>>>>>> >> starlink advertises its customer ip address location at
>>>>>>> >> http://geoip.starlinkisp.net (not always updated but good enough in
>>>>>>> >> most cases and traceroute can confirm to some extent as well)
>>>>>>> >> --
>>>>>>> >> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan at UVic.CA,
>>>>>>> Web.UVic.CA/~pan <http://Web.UVic.CA/~pan>
>>>>>>> >>
>>>>>>> >> On Sun, Dec 3, 2023 at 4:15 PM Noel Butler via Starlink
>>>>>>> >> <starlink at lists.bufferbloat.net> wrote:
>>>>>>> >>
>>>>>>> >>
>>>>>>> >> I run an open access usenet server, but only for those within
>>>>>>> my CC, so access is by IP based on our CC allocations from APNIC.
>>>>>>> >>
>>>>>>> >> Because IPv4 exhaustion this changes sometimes with buying
>>>>>>> allocations from other regions, and if they get denied access I
>>>>>>> encourage them to let us know so we can keep ACL's updated, I've
>>>>>>> had a request from a starlink user who claims they are here, but
>>>>>>> traceroute shows them in .DE
>>>>>>> >>
>>>>>>> >> tracing some 217.foo.ad.dr
>>>>>>> >>
>>>>>>> >> ...
>>>>>>> >> 9 ae-6.r21.frnkge13.de.bb.gin.ntt.net
>>>>>>> <http://ae-6.r21.frnkge13.de.bb.gin.ntt.net> (129.250.3.183)
>>>>>>> 290.223 ms 290.180 ms ae-1.r20.frnkge13.de.bb.gin.ntt.net
>>>>>>> <http://ae-1.r20.frnkge13.de.bb.gin.ntt.net> (129.250.7.35) 280.523 ms
>>>>>>> >> 10 ae-1.a03.frnkge13.de.bb.gin.ntt.net
>>>>>>> <http://ae-1.a03.frnkge13.de.bb.gin.ntt.net> (129.250.3.152)
>>>>>>> 290.109 ms 289.667 ms 292.864 ms
>>>>>>> >> 11 ae-0.spacex.frnkge13.de.bb.gin.ntt.net
>>>>>>> <http://ae-0.spacex.frnkge13.de.bb.gin.ntt.net> (213.198.72.19)
>>>>>>> 279.611 ms 278.840 ms 279.592 ms
>>>>>>> >> 12 undefined.hostname.localhost (206.224.65.189) 280.127 ms
>>>>>>> 278.506 ms 284.265 ms
>>>>>>> >> 13 undefined.hostname.localhost (206.224.65.209) 284.198 ms
>>>>>>> undefined.hostname.localhost (206.224.65.201) 274.663 ms 273.073 ms
>>>>>>> >> 14 * * *
>>>>>>> >>
>>>>>>> >>
>>>>>>> >> As it is our policy to not collect any user info or issue
>>>>>>> user/pass's and only allow access by IP, I'm hoping someone here
>>>>>>> knows if they are full of it, or does starlink really assign
>>>>>>> addresses from anywhere? That one hardly makes sense for user
>>>>>>> experience, or maybe starlink has so few users in this country
>>>>>>> they haven't bothered changing anything yet?
>>>>>>> >>
>>>>>>> >> --
>>>>>>> >>
>>>>>>> >> Regards,
>>>>>>> >> Noel Butler
>>>>>>> >>
>>>>>>> >>
>>>>>>> >> _______________________________________________
>>>>>>> >> Starlink mailing list
>>>>>>> >> Starlink at lists.bufferbloat.net
>>>>>>> >> https://lists.bufferbloat.net/listinfo/starlink
>>>>>>> >>
>>>>>>> >>
>>>>>>> >> --
>>>>>>> >>
>>>>>>> >> Regards,
>>>>>>> >> Noel Butler
>>>>>>> >>
>>>>>>> >>
>>>>>>> > _______________________________________________
>>>>>>> > 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
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Starlink mailing list
>>>>>> Starlink at lists.bufferbloat.net
>>>>>> https://lists.bufferbloat.net/listinfo/starlink
More information about the Starlink
mailing list