[Starlink] Info on IP country ranges
Alexandre Petrescu
alexandre.petrescu at gmail.com
Fri Dec 8 03:37:37 EST 2023
Le 08/12/2023 à 09:30, Alexandre Petrescu via Starlink a écrit :
>
> 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).
For clarification: there could be a way to make a /56 out of a /128 out
of that /64. The way to do that is to do tunnelling - a third party
router would use a tunnelling gateway outside the starlink domain. But
tunnelling means addition of latency. That would not be an incentive.
Alex
>
> 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