[Starlink] Info on IP country ranges

[Starlink] Info on IP country ranges

[Noel Butler]

[-- Attachment #1: Type: text/plain, Size: 1374 bytes --]

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 (129.250.3.183) 290.223 ms 290.180 
ms 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 (129.250.3.152) 290.109 ms 
289.667 ms 292.864 ms
11 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

[-- Attachment #2: Type: text/html, Size: 1713 bytes --]

Re: [Starlink] Info on IP country ranges

[J Pan]

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@UVic.CA, Web.UVic.CA/~pan

On Sun, Dec 3, 2023 at 4:15 PM Noel Butler via Starlink
<starlink@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 (129.250.3.183) 290.223 ms 290.180 ms 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 (129.250.3.152) 290.109 ms 289.667 ms 292.864 ms
> 11 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@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] Info on IP country ranges

[Noel Butler]

[-- Attachment #1: Type: text/plain, Size: 2146 bytes --]

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@UVic.CA, 
> Web.UVic.CA/~pan
> 
> On Sun, Dec 3, 2023 at 4:15 PM Noel Butler via Starlink
> <starlink@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 (129.250.3.183) 290.223 ms 
>> 290.180 ms 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 (129.250.3.152) 290.109 ms 
>> 289.667 ms 292.864 ms
>> 11 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@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink

-- 
Regards,
Noel Butler

[-- Attachment #2: Type: text/html, Size: 3075 bytes --]

Re: [Starlink] Info on IP country ranges

[J Pan]

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 ;-)
--
J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan

On Mon, Dec 4, 2023 at 4:04 AM Noel Butler <noel.butler@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@UVic.CA, Web.UVic.CA/~pan
>
> On Sun, Dec 3, 2023 at 4:15 PM Noel Butler via Starlink
> <starlink@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 (129.250.3.183) 290.223 ms 290.180 ms 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 (129.250.3.152) 290.109 ms 289.667 ms 292.864 ms
> 11 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@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>
>
> --
>
> Regards,
> Noel Butler
>
>

Re: [Starlink] Info on IP country ranges

[Alexandre Petrescu]

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@UVic.CA, Web.UVic.CA/~pan
>
> On Mon, Dec 4, 2023 at 4:04 AM Noel Butler <noel.butler@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@UVic.CA, Web.UVic.CA/~pan
>>
>> On Sun, Dec 3, 2023 at 4:15 PM Noel Butler via Starlink
>> <starlink@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 (129.250.3.183) 290.223 ms 290.180 ms 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 (129.250.3.152) 290.109 ms 289.667 ms 292.864 ms
>> 11 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@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
>>
>>
>> --
>>
>> Regards,
>> Noel Butler
>>
>>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] Info on IP country ranges

[J Pan]

yes, user router gets a public ipv6 address block from starlink to
distribute in its local network. starlink network is ipv6 native
(although www.starlink.com is not accessible by ipv6 yet, while
geoip.starlinkisp.net is----the classic fight between noc, nic and
nmc---network measurement center people ;-) on the other hand,
starlink-provided user router does not support configuration to allow
incoming connections. users can bypass it and use their more
configurable router, but still have to use the stock one for
power-over-ethernet for gen-2 dishes ;-)
--
J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan

On Thu, Dec 7, 2023 at 3:55 AM Alexandre Petrescu via Starlink
<starlink@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@UVic.CA, Web.UVic.CA/~pan
> >
> > On Mon, Dec 4, 2023 at 4:04 AM Noel Butler <noel.butler@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@UVic.CA, Web.UVic.CA/~pan
> >>
> >> On Sun, Dec 3, 2023 at 4:15 PM Noel Butler via Starlink
> >> <starlink@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 (129.250.3.183) 290.223 ms 290.180 ms 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 (129.250.3.152) 290.109 ms 289.667 ms 292.864 ms
> >> 11 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@lists.bufferbloat.net
> >> https://lists.bufferbloat.net/listinfo/starlink
> >>
> >>
> >> --
> >>
> >> Regards,
> >> Noel Butler
> >>
> >>
> > _______________________________________________
> > Starlink mailing list
> > Starlink@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/starlink
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] Info on IP country ranges

[Alexandre Petrescu]

Le 07/12/2023 à 19:07, J Pan a écrit :
> yes, user router gets a public ipv6 address block from starlink to
> distribute in its local network.

What is the size of the block?

Alex

>   starlink network is ipv6 native
> (although www.starlink.com is not accessible by ipv6 yet, while
> geoip.starlinkisp.net is----the classic fight between noc, nic and
> nmc---network measurement center people ;-) on the other hand,
> starlink-provided user router does not support configuration to allow
> incoming connections. users can bypass it and use their more
> configurable router, but still have to use the stock one for
> power-over-ethernet for gen-2 dishes ;-)
> --
> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan
>
> On Thu, Dec 7, 2023 at 3:55 AM Alexandre Petrescu via Starlink
> <starlink@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@UVic.CA, Web.UVic.CA/~pan
>>>
>>> On Mon, Dec 4, 2023 at 4:04 AM Noel Butler <noel.butler@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@UVic.CA, Web.UVic.CA/~pan
>>>>
>>>> On Sun, Dec 3, 2023 at 4:15 PM Noel Butler via Starlink
>>>> <starlink@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 (129.250.3.183) 290.223 ms 290.180 ms 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 (129.250.3.152) 290.109 ms 289.667 ms 292.864 ms
>>>> 11 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@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/starlink
>>>>
>>>>
>>>> --
>>>>
>>>> Regards,
>>>> Noel Butler
>>>>
>>>>
>>> _______________________________________________
>>> Starlink mailing list
>>> Starlink@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/starlink
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] Info on IP country ranges

[David Lang]

On Thu, 7 Dec 2023, J Pan via Starlink wrote:

> but still have to use the stock one for
> power-over-ethernet for gen-2 dishes ;-)

Thee are ways to power the square dishies without the router. You can cut the 
cable, or buy an adapter to run to a PoE or buy a combination adapter/PoE

David Lang

Re: [Starlink] Info on IP country ranges

[Freddie Cash]

[-- Attachment #1: Type: text/plain, Size: 4754 bytes --]

Dishy gets a /64 and I've tested DHCPv6 on both my Firewalla and my USG.
They do prefix delegation to distribute that as a /56 locally.

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@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@UVic.CA,
> Web.UVic.CA/~pan
> >
> > On Mon, Dec 4, 2023 at 4:04 AM Noel Butler <noel.butler@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@UVic.CA,
> Web.UVic.CA/~pan
> >>
> >> On Sun, Dec 3, 2023 at 4:15 PM Noel Butler via Starlink
> >> <starlink@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 (129.250.3.183) 290.223 ms
> 290.180 ms 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 (129.250.3.152) 290.109 ms
> 289.667 ms 292.864 ms
> >> 11 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@lists.bufferbloat.net
> >> https://lists.bufferbloat.net/listinfo/starlink
> >>
> >>
> >> --
> >>
> >> Regards,
> >> Noel Butler
> >>
> >>
> > _______________________________________________
> > Starlink mailing list
> > Starlink@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/starlink
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>

[-- Attachment #2: Type: text/html, Size: 7123 bytes --]

Re: [Starlink] Info on IP country ranges

[Alexandre Petrescu]

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@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@UVic.CA,
>     Web.UVic.CA/~pan <http://Web.UVic.CA/~pan>
>     >
>     > On Mon, Dec 4, 2023 at 4:04 AM Noel Butler
>     <noel.butler@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@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@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@lists.bufferbloat.net
>     >> https://lists.bufferbloat.net/listinfo/starlink
>     >>
>     >>
>     >> --
>     >>
>     >> Regards,
>     >> Noel Butler
>     >>
>     >>
>     > _______________________________________________
>     > Starlink mailing list
>     > Starlink@lists.bufferbloat.net
>     > https://lists.bufferbloat.net/listinfo/starlink
>     _______________________________________________
>     Starlink mailing list
>     Starlink@lists.bufferbloat.net
>     https://lists.bufferbloat.net/listinfo/starlink
>

Re: [Starlink] Info on IP country ranges

[Alexandre Petrescu]

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@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@UVic.CA,
>>     Web.UVic.CA/~pan <http://Web.UVic.CA/~pan>
>>     >
>>     > On Mon, Dec 4, 2023 at 4:04 AM Noel Butler
>>     <noel.butler@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@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@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@lists.bufferbloat.net
>>     >> https://lists.bufferbloat.net/listinfo/starlink
>>     >>
>>     >>
>>     >> --
>>     >>
>>     >> Regards,
>>     >> Noel Butler
>>     >>
>>     >>
>>     > _______________________________________________
>>     > Starlink mailing list
>>     > Starlink@lists.bufferbloat.net
>>     > https://lists.bufferbloat.net/listinfo/starlink
>>     _______________________________________________
>>     Starlink mailing list
>>     Starlink@lists.bufferbloat.net
>>     https://lists.bufferbloat.net/listinfo/starlink
>>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] Info on IP country ranges

[Steven]

You do indeed get a /56, so are able to assign unique /64s to each of your networks.

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).

You can then request a /56 using DHCP-PD (separate to the /64 used on the WAN interface).

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@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@UVic.CA,
>>     Web.UVic.CA/~pan <http://Web.UVic.CA/~pan>
>>     >
>>     > On Mon, Dec 4, 2023 at 4:04 AM Noel Butler
>>     <noel.butler@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@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@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@lists.bufferbloat.net
>>     >> https://lists.bufferbloat.net/listinfo/starlink
>>     >>
>>     >>
>>     >> --
>>     >>
>>     >> Regards,
>>     >> Noel Butler
>>     >>
>>     >>
>>     > _______________________________________________
>>     > Starlink mailing list
>>     > Starlink@lists.bufferbloat.net
>>     > https://lists.bufferbloat.net/listinfo/starlink
>>     _______________________________________________
>>     Starlink mailing list
>>     Starlink@lists.bufferbloat.net
>>     https://lists.bufferbloat.net/listinfo/starlink
>>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] Info on IP country ranges

[Alexandre Petrescu]

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@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@UVic.CA,
>>>      Web.UVic.CA/~pan <http://Web.UVic.CA/~pan>
>>>      >
>>>      > On Mon, Dec 4, 2023 at 4:04 AM Noel Butler
>>>      <noel.butler@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@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@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@lists.bufferbloat.net
>>>      >> https://lists.bufferbloat.net/listinfo/starlink
>>>      >>
>>>      >>
>>>      >> --
>>>      >>
>>>      >> Regards,
>>>      >> Noel Butler
>>>      >>
>>>      >>
>>>      > _______________________________________________
>>>      > Starlink mailing list
>>>      > Starlink@lists.bufferbloat.net
>>>      > https://lists.bufferbloat.net/listinfo/starlink
>>>      _______________________________________________
>>>      Starlink mailing list
>>>      Starlink@lists.bufferbloat.net
>>>      https://lists.bufferbloat.net/listinfo/starlink
>>>
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] Info on IP country ranges

[Alexandre Petrescu]

Le 08/12/2023 à 09:40, Steven a écrit :
> 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).


This - /64 shared among customers, or unique per customer - is an 
excellent question that deserves attention.

Alex

>
> You can then request a /56 using DHCP-PD (separate to the /64 used on the WAN interface).
>
> 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@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@UVic.CA,
>>>      Web.UVic.CA/~pan <http://Web.UVic.CA/~pan>
>>>      >
>>>      > On Mon, Dec 4, 2023 at 4:04 AM Noel Butler
>>>      <noel.butler@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@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@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@lists.bufferbloat.net
>>>      >> https://lists.bufferbloat.net/listinfo/starlink
>>>      >>
>>>      >>
>>>      >> --
>>>      >>
>>>      >> Regards,
>>>      >> Noel Butler
>>>      >>
>>>      >>
>>>      > _______________________________________________
>>>      > Starlink mailing list
>>>      > Starlink@lists.bufferbloat.net
>>>      > https://lists.bufferbloat.net/listinfo/starlink
>>>      _______________________________________________
>>>      Starlink mailing list
>>>      Starlink@lists.bufferbloat.net
>>>      https://lists.bufferbloat.net/listinfo/starlink
>>>
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] Info on IP country ranges

[Gert Doering]

Hi,

On Fri, Dec 08, 2023 at 11:28:10AM +0100, Alexandre Petrescu via Starlink wrote:
> Le 08/12/2023 à 09:40, Steven a écrit :
> > 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).
> 
> This - /64 shared among customers, or unique per customer - is an excellent
> question that deserves attention.

Actually it's pretty much a non-question, since nobody with a global
network would even consider doing "a /64 shared among customers".

There's no benefit in doing this, and the amount of obvious reasons to
*not* do this are more than I want to type right now.  Like, ND traffic,
global routing, RTTs, ...

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

Re: [Starlink] Info on IP country ranges

[Steven]

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.

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@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@UVic.CA,
>>>>      Web.UVic.CA/~pan <http://Web.UVic.CA/~pan>
>>>>      >
>>>>      > On Mon, Dec 4, 2023 at 4:04 AM Noel Butler
>>>>      <noel.butler@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@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@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@lists.bufferbloat.net
>>>>      >> https://lists.bufferbloat.net/listinfo/starlink
>>>>      >>
>>>>      >>
>>>>      >> --
>>>>      >>
>>>>      >> Regards,
>>>>      >> Noel Butler
>>>>      >>
>>>>      >>
>>>>      > _______________________________________________
>>>>      > Starlink mailing list
>>>>      > Starlink@lists.bufferbloat.net
>>>>      > https://lists.bufferbloat.net/listinfo/starlink
>>>>      _______________________________________________
>>>>      Starlink mailing list
>>>>      Starlink@lists.bufferbloat.net
>>>>      https://lists.bufferbloat.net/listinfo/starlink
>>>>
>>> _______________________________________________
>>> Starlink mailing list
>>> Starlink@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] Info on IP country ranges

[Alexandre Petrescu]

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@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@UVic.CA,
>>>>>       Web.UVic.CA/~pan <http://Web.UVic.CA/~pan>
>>>>>       >
>>>>>       > On Mon, Dec 4, 2023 at 4:04 AM Noel Butler
>>>>>       <noel.butler@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@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@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@lists.bufferbloat.net
>>>>>       >> https://lists.bufferbloat.net/listinfo/starlink
>>>>>       >>
>>>>>       >>
>>>>>       >> --
>>>>>       >>
>>>>>       >> Regards,
>>>>>       >> Noel Butler
>>>>>       >>
>>>>>       >>
>>>>>       > _______________________________________________
>>>>>       > Starlink mailing list
>>>>>       > Starlink@lists.bufferbloat.net
>>>>>       > https://lists.bufferbloat.net/listinfo/starlink
>>>>>       _______________________________________________
>>>>>       Starlink mailing list
>>>>>       Starlink@lists.bufferbloat.net
>>>>>       https://lists.bufferbloat.net/listinfo/starlink
>>>>>
>>>> _______________________________________________
>>>> Starlink mailing list
>>>> Starlink@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] Info on IP country ranges

[Steven]

Alexandre,

I'm confident it is a Starlink provided /56 for a number of reasons.

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.
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.
3. The /56 is from a Starlink allocation, as verified by bgp.tools.
4. Numerous others have also obtained a /56 using DHCPv6-PD from Starlink. A quick internet search will yield many others.

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@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@UVic.CA,
>>>>>>       Web.UVic.CA/~pan <http://Web.UVic.CA/~pan>
>>>>>>       >
>>>>>>       > On Mon, Dec 4, 2023 at 4:04 AM Noel Butler
>>>>>>       <noel.butler@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@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@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@lists.bufferbloat.net
>>>>>>       >> https://lists.bufferbloat.net/listinfo/starlink
>>>>>>       >>
>>>>>>       >>
>>>>>>       >> --
>>>>>>       >>
>>>>>>       >> Regards,
>>>>>>       >> Noel Butler
>>>>>>       >>
>>>>>>       >>
>>>>>>       > _______________________________________________
>>>>>>       > Starlink mailing list
>>>>>>       > Starlink@lists.bufferbloat.net
>>>>>>       > https://lists.bufferbloat.net/listinfo/starlink
>>>>>>       _______________________________________________
>>>>>>       Starlink mailing list
>>>>>>       Starlink@lists.bufferbloat.net
>>>>>>       https://lists.bufferbloat.net/listinfo/starlink
>>>>>>
>>>>> _______________________________________________
>>>>> Starlink mailing list
>>>>> Starlink@lists.bufferbloat.net
>>>>> https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] Info on IP country ranges

[Alexandre Petrescu]

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@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@UVic.CA,
>>>>>>>        Web.UVic.CA/~pan <http://Web.UVic.CA/~pan>
>>>>>>>        >
>>>>>>>        > On Mon, Dec 4, 2023 at 4:04 AM Noel Butler
>>>>>>>        <noel.butler@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@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@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@lists.bufferbloat.net
>>>>>>>        >> https://lists.bufferbloat.net/listinfo/starlink
>>>>>>>        >>
>>>>>>>        >>
>>>>>>>        >> --
>>>>>>>        >>
>>>>>>>        >> Regards,
>>>>>>>        >> Noel Butler
>>>>>>>        >>
>>>>>>>        >>
>>>>>>>        > _______________________________________________
>>>>>>>        > Starlink mailing list
>>>>>>>        > Starlink@lists.bufferbloat.net
>>>>>>>        > https://lists.bufferbloat.net/listinfo/starlink
>>>>>>>        _______________________________________________
>>>>>>>        Starlink mailing list
>>>>>>>        Starlink@lists.bufferbloat.net
>>>>>>>        https://lists.bufferbloat.net/listinfo/starlink
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Starlink mailing list
>>>>>> Starlink@lists.bufferbloat.net
>>>>>> https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] Info on IP country ranges

[Steven]

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

Re: [Starlink] Info on IP country ranges

[Alexandre Petrescu]

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...
True, it would be unusual, but it is practiced.
>
>> 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.

YEs, that latency argument is a good reason.


>
>> 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.

Thanks.  That convinces me it is as you say: the /56 is provided by the 
starlink DHCPv6-PD server situated in the ground network of starlink 
somewhere.

This makes it for a great tool for many things.

Alex

>
> Cheers,
> Steven

Re: [Starlink] Info on IP country ranges

[Alexandre Petrescu]

Le 08/12/2023 à 13:46, Alexandre Petrescu via Starlink a écrit :
>
> 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...
> True, it would be unusual, but it is practiced.
>>
>>> 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.
>
> YEs, that latency argument is a good reason.
>
>
>>
>>> 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.
>
> Thanks.  That convinces me it is as you say: the /56 is provided by 
> the starlink DHCPv6-PD server situated in the ground network of 
> starlink somewhere.
>
> This makes it for a great tool for many things.


Sorry for having been cryptic  about 'many things' - I meant to say that 
I hope that MikroTik querying the DHCPv6-PD server in the starlink 
infrastructure might work ok from  a car as well.  This would be one big 
advantage of using starlink instead of a 4G-5G link in a car (the 4G-5G 
cellular networks only give /64s to end users, and the android 
smartphones dont run DHCPv6-PD Clients).

Alex

>
> Alex
>
>>
>> Cheers,
>> Steven
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] Info on IP country ranges

[Freddie Cash]

[-- Attachment #1: Type: text/plain, Size: 7395 bytes --]

Sorry, you're right, I got that wrong. Was going from memory.

Checking the Firewalla, it's a /64 on both the WAN (via DHCPv6) and LAN
interfaces (via prefix delegation).

Cheers,
Freddie

Typos due to smartphone keyboard.

On Fri, Dec 8, 2023, 12:37 a.m. Alexandre Petrescu via Starlink <
starlink@lists.bufferbloat.net> wrote:

>
> 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@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@UVic.CA,
> >>     Web.UVic.CA/~pan <http://Web.UVic.CA/~pan>
> >>     >
> >>     > On Mon, Dec 4, 2023 at 4:04 AM Noel Butler
> >>     <noel.butler@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@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@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@lists.bufferbloat.net
> >>     >> https://lists.bufferbloat.net/listinfo/starlink
> >>     >>
> >>     >>
> >>     >> --
> >>     >>
> >>     >> Regards,
> >>     >> Noel Butler
> >>     >>
> >>     >>
> >>     > _______________________________________________
> >>     > Starlink mailing list
> >>     > Starlink@lists.bufferbloat.net
> >>     > https://lists.bufferbloat.net/listinfo/starlink
> >>     _______________________________________________
> >>     Starlink mailing list
> >>     Starlink@lists.bufferbloat.net
> >>     https://lists.bufferbloat.net/listinfo/starlink
> >>
> > _______________________________________________
> > Starlink mailing list
> > Starlink@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/starlink
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>

[-- Attachment #2: Type: text/html, Size: 12660 bytes --]

Re: [Starlink] Info on IP country ranges

[Alexandre Petrescu]

Le 08/12/2023 à 16:27, Freddie Cash a écrit :
> Sorry, you're right, I got that wrong. Was going from memory.
>
> Checking the Firewalla, it's a /64 on both the WAN (via DHCPv6) and 
> LAN interfaces (via prefix delegation).

Sure, it can be that way.

The key question was, and it is now clarified, whether starlink gives a 
/56 to the end user or not.  I understand it does: there is a DHCPv6-PD 
Server in the starlink ground infrastructure; it responds to DHCPv6-PD 
requests issued from home by a DHCPv6-PD Client; it allocates a /56.

Then, how is that /56 used in home - how is it split into /64s (there 
are many ways to split a hair), how is it put on interfaces of Firewalla 
(a name I dont know), how is it further delegated inside the home 
network, is another matter.  There can be many ways of doing it.  The 
DHCPv6-PD Client on firewalla can also act as a DHCPv6-PD Server on the 
firewalla.   Or not.  There could be DHCPv6-PD Relay in the Firewalla, 
or elsewhere in home as well. The topology can be discussed, 
implemented, there would be no problem.

The key advantage of starlink compared to cellular networks is in that 
it gives that /56.

Alex

>
> Cheers,
> Freddie
>
> Typos due to smartphone keyboard.
>
> On Fri, Dec 8, 2023, 12:37 a.m. Alexandre Petrescu via Starlink 
> <starlink@lists.bufferbloat.net> wrote:
>
>
>     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@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@UVic.CA,
>     >> Web.UVic.CA/~pan <http://Web.UVic.CA/~pan>
>     <http://Web.UVic.CA/~pan <http://Web.UVic.CA/~pan>>
>     >>     >
>     >>     > On Mon, Dec 4, 2023 at 4:04 AM Noel Butler
>     >>     <noel.butler@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@UVic.CA,
>     >> Web.UVic.CA/~pan <http://Web.UVic.CA/~pan>
>     <http://Web.UVic.CA/~pan <http://Web.UVic.CA/~pan>>
>     >>     >>
>     >>     >> On Sun, Dec 3, 2023 at 4:15 PM Noel Butler via Starlink
>     >>     >> <starlink@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>
>     >>     <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>
>     >>     <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>
>     >>     <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>
>     >>     <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@lists.bufferbloat.net
>     >>     >> https://lists.bufferbloat.net/listinfo/starlink
>     >>     >>
>     >>     >>
>     >>     >> --
>     >>     >>
>     >>     >> Regards,
>     >>     >> Noel Butler
>     >>     >>
>     >>     >>
>     >>     > _______________________________________________
>     >>     > Starlink mailing list
>     >>     > Starlink@lists.bufferbloat.net
>     >>     > https://lists.bufferbloat.net/listinfo/starlink
>     >>     _______________________________________________
>     >>     Starlink mailing list
>     >> Starlink@lists.bufferbloat.net
>     >> https://lists.bufferbloat.net/listinfo/starlink
>     >>
>     > _______________________________________________
>     > Starlink mailing list
>     > Starlink@lists.bufferbloat.net
>     > https://lists.bufferbloat.net/listinfo/starlink
>     _______________________________________________
>     Starlink mailing list
>     Starlink@lists.bufferbloat.net
>     https://lists.bufferbloat.net/listinfo/starlink
>

Re: [Starlink] Info on IP country ranges

[Alexandre Petrescu]

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

Re: [Starlink] Info on IP country ranges

[Steven Honson]

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

Re: [Starlink] Info on IP country ranges

[J Pan]

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

Re: [Starlink] Info on IP country ranges

[Steven]

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.

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

Re: [Starlink] Info on IP country ranges

[Alexandre Petrescu]

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

Re: [Starlink] Info on IP country ranges

[Steven]

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.

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

Re: [Starlink] Info on IP country ranges

[Sebastian Moeller]

Hi Steven,



> On Dec 12, 2023, at 11:33, Steven via Starlink <starlink@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?

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@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
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] Info on IP country ranges

[Alexandre Petrescu]

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

Re: [Starlink] Info on IP country ranges

[Alexandre Petrescu]

Le 12/12/2023 à 11:50, Sebastian Moeller a écrit :
> Hi Steven,
>
>
>
>> On Dec 12, 2023, at 11:33, Steven via Starlink <starlink@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.

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).

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@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
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] Info on IP country ranges

[Marc Blanchet]

> Le 13 déc. 2023 à 05:33, Alexandre Petrescu via Starlink <starlink@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@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@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
>>> _______________________________________________
>>> Starlink mailing list
>>> Starlink@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/starlink
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] Info on IP country ranges

[David Lang]

[-- Attachment #1: Type: text/plain, Size: 2036 bytes --]

On Wed, 13 Dec 2023, Alexandre Petrescu via Starlink wrote:

> 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.
>
> 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).

There are two types of keeping your address. One is to have the same address all 
the time, the other is to keep your address during a session.

Even if you get a public address, it can change from time to time (just like 
DHCP addresses could on landline ISPs), but that doesn't mean that your address 
will change during a session (i.e. while you are powered up and connected) even 
while moving around.

If you get a public IP, that IP will change like a DHCP address would on a 
landline ISP, rarely and mostly when equipment at one end or another was 
restarted, but not every time you do a new satellite handoff

David Lang

Re: [Starlink] Info on IP country ranges

[Alexandre Petrescu]

Le 13/12/2023 à 19:27, David Lang a écrit :
> On Wed, 13 Dec 2023, Alexandre Petrescu via Starlink wrote:
>
>> 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.
>>
>> 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).
>
> There are two types of keeping your address. One is to have the same 
> address all the time, the other is to keep your address during a session.
Fair enough.
>
> Even if you get a public address, it can change from time to time 
> (just like DHCP addresses could on landline ISPs), 

Well, it depends on ISP.  Indeed some wireline ISPs change the address 
of home customers relatively often - on DHCP lease expiry, MAC-less or 
NAI-less DHCP during reboots, etc.  But other landline ISPs do provide 
always the same IP address to customers.  Some times it is even part of 
the signed contract.


> but that doesn't mean that your address will change during a session 
> (i.e. while you are powered up and connected) even while moving around.

Do you mean that the /56 I'd get from starlink with DHCPv6-PD would stay 
the same if I had ongoing sessions, and moved in and out the hexagon 
cells,or even in-out of a teleport coverage? (driving a car on a longer 
distance).

Remark that /56 can not be equated simply to the behaviour of an IPv4 
address.  That /56 means more than just one address and, additionally, 
it is bound to an IPv6 address to which it is routed (either a GUA or a 
LL, a 'next-hop' address).

The maintenance of that /56 constant can happen with or without 
maintenance of the 'next-hop' address constant.

If starlink keeps constant both the 'next-hop' address and the allocated 
/56 during movements to very wide distances (cell-to-cell, 
teleport-to-teleport) then it could some options.

If starlink keeps constant just the /56 allocated to end user, and 
varies the 'next-hop' address attached to it then it would other options.

There are design options.

>
> If you get a public IP, that IP will change like a DHCP address would 
> on a landline ISP, rarely and mostly when equipment at one end or 
> another was restarted, but not every time you do a new satellite handoff

satellite handoff: do you mean the handoff provoked by the movement of 
satellites to a ground-fixed user, or do you mean the movement of end 
user in and out of hexagon cells covered by satellites?

IMHO, I think it can mean either of the two.  For the latter (movement 
of end user between cells) there'd probably be another /56 delegated to 
an end user, regardless of having ongoing sessions - DHCP does not check 
the status of apps.

Further, a very wide area movement might provoke a change in teleport, 
not just a change in hexagon cells.  A change in teleport certainly 
provokes a change in the allocated /56 of the end user, again regardless 
of her having running sessions.  In order to keep a same /56 allocated 
to a same end user handed over from one teleport to another there would 
be a need of some teleport-to-teleport protocol, maybe a tunnelled BGP, 
or other.

Alex


>
> David Lang

Re: [Starlink] Info on IP country ranges

[J Pan]

starlink uses tunnels a lot
https://www.reddit.com/r/StarlinkEngineering/comments/17w3sey/a_better_illustration_about_starlink_user/
. starlink assigned ip addresses are pop-specific
--
J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan

Re: [Starlink] Info on IP country ranges

[Alexandre Petrescu]

Le 23/12/2023 à 22:35, J Pan a écrit :
> starlink uses tunnels a lot
> https://www.reddit.com/r/StarlinkEngineering/comments/17w3sey/a_better_illustration_about_starlink_user/
> . starlink assigned ip addresses are pop-specific
> --
> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan

That is a good point.  Thank you for the figure!

I will discuss it separately, if appropriate.

Alex

Re: [Starlink] starlink topology with tunnels (was: Info on IP country ranges)

[Alexandre Petrescu]

The figure of starlink topology with tunnels is in the attachment of 
this email.  It comes from 
https://www.reddit.com/r/StarlinkEngineering/comments/17w3sey/a_better_illustration_about_starlink_user/

The original poster's text about the figure is: "a better illustration 
about starlink user terminal (ut), community gateway (cg), ground 
station (gs), gateway (gw), carrier-grade network address translator 
(cgnat), point-of-presence (pop), etc ".

It is a user oppinion.

Alex


Le 06/01/2024 à 16:01, Alexandre Petrescu via Starlink a écrit :
>
>
> Le 23/12/2023 à 22:35, J Pan a écrit :
>> starlink uses tunnels a lot
>> https://www.reddit.com/r/StarlinkEngineering/comments/17w3sey/a_better_illustration_about_starlink_user/ 
>>
>> . starlink assigned ip addresses are pop-specific
>> -- 
>> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, 
>> Web.UVic.CA/~pan
>
> That is a good point.  Thank you for the figure!
>
> I will discuss it separately, if appropriate.
>
> Alex
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] starlink topology with tunnels

[Alexandre PETRESCU]

[-- Attachment #1: Type: text/plain, Size: 1339 bytes --]

[with the attachment, sorry]

The figure of starlink topology with tunnels is in the attachment of 
this email.  It comes from 
https://www.reddit.com/r/StarlinkEngineering/comments/17w3sey/a_better_illustration_about_starlink_user/

The original poster's text about the figure is: "a better illustration 
about starlink user terminal (ut), community gateway (cg), ground 
station (gs), gateway (gw), carrier-grade network address translator 
(cgnat), point-of-presence (pop), etc ".

It is a user opinion.

Alex


Le 06/01/2024 à 16:01, Alexandre Petrescu via Starlink a écrit :
>
>
> Le 23/12/2023 à 22:35, J Pan a écrit :
>> starlink uses tunnels a lot
>> https://www.reddit.com/r/StarlinkEngineering/comments/17w3sey/a_better_illustration_about_starlink_user/ 
>>
>> . starlink assigned ip addresses are pop-specific
>> -- 
>> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, 
>> Web.UVic.CA/~pan
>
> That is a good point.  Thank you for the figure!
>
> I will discuss it separately, if appropriate.
>
> Alex
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink

[-- Attachment #2: 7r3tjmjntk0c1.png --]
[-- Type: image/png, Size: 15980 bytes --]

Re: [Starlink] Info on IP country ranges

[Alexandre Petrescu]

Le 08/01/2024 à 11:54, Sebastian Moeller a écrit :
>> On Jan 6, 2024, at 16:06, Dave Taht via Starlink <starlink@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...

I have never used Mobile Shell mosh, but I consider it.  I might try it 
on my windows, if it exists.

I read that it uses UDP.  This might make it very usable for (errr...) 
telnetting into computers situated deeper in space, like near Mars or 
so.  It was said (on the deepspace email list at IETF) that telnetting 
into such a remote computer might not work because of long latencies (I 
vaguely remember 40hours(?) RTT). The bandwidth is not a problem, 
because the current systems seem to feature hundreds of megabits per 
second to such distant computers, but the echo of a key press is 
certainly a matter of latency, and that might be a matter of TCP.  It 
might be possible to 'script' that, but a client using UDP might be much 
more performant.

Other than that, it would be interesting to know whether mosh's security 
(I read AES-128 'OCB3' mode) is resistant to brute force attacks from 
very strong computers such as those with ambiguous states in bits.  
Because ssh implementations do feature 'quantum resistance' and thus 
they might be preferable from the security standpoint.

Alex

>
>
>
>
>> On Sat, Jan 6, 2024 at 9:59 AM Alexandre Petrescu via Starlink
>> <starlink@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@lists.bufferbloat.net> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Le 13 déc. 2023 à 15:58, David Fernández via Starlink
>>>>>> <starlink@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@viagenie.ca>
>>>>>>> To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
>>>>>>> Cc: Sebastian Moeller <moeller0@gmx.de>, Steven
>>>>>>> <bufferbloat-lists@steven.honson.au>, starlink@lists.bufferbloat.net
>>>>>>> Subject: Re: [Starlink] Info on IP country ranges
>>>>>>> Message-ID: <1FE6B070-C2A0-4C35-8876-33FEDED81F69@viagenie.ca>
>>>>>>> Content-Type: text/plain;charset=utf-8
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Le 13 déc. 2023 à 05:33, Alexandre Petrescu via Starlink
>>>>>>>> <starlink@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@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@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
>>>>> _______________________________________________
>>>>> Starlink mailing list
>>>>> Starlink@lists.bufferbloat.net <mailto:Starlink@lists.bufferbloat.net>
>>>>> https://lists.bufferbloat.net/listinfo/starlink
>>>>> <https://lists.bufferbloat.net/listinfo/starlink>
>>>>
>>>> _______________________________________________
>>>> Starlink mailing list
>>>> Starlink@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/starlink
>>> _______________________________________________
>>> Starlink mailing list
>>> Starlink@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@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] Info on IP country ranges

[Sebastian Moeller]

> On Jan 6, 2024, at 16:06, Dave Taht via Starlink <starlink@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@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@lists.bufferbloat.net> wrote:
>>>> 
>>>> 
>>>> 
>>>>> Le 13 déc. 2023 à 15:58, David Fernández via Starlink
>>>>> <starlink@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@viagenie.ca>
>>>>>> To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
>>>>>> Cc: Sebastian Moeller <moeller0@gmx.de>, Steven
>>>>>> <bufferbloat-lists@steven.honson.au>, starlink@lists.bufferbloat.net
>>>>>> Subject: Re: [Starlink] Info on IP country ranges
>>>>>> Message-ID: <1FE6B070-C2A0-4C35-8876-33FEDED81F69@viagenie.ca>
>>>>>> Content-Type: text/plain;charset=utf-8
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> Le 13 déc. 2023 à 05:33, Alexandre Petrescu via Starlink
>>>>>>> <starlink@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@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@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
>>>> 
>>>> _______________________________________________
>>>> Starlink mailing list
>>>> Starlink@lists.bufferbloat.net <mailto:Starlink@lists.bufferbloat.net>
>>>> https://lists.bufferbloat.net/listinfo/starlink
>>>> <https://lists.bufferbloat.net/listinfo/starlink>
>>> 
>>> 
>>> _______________________________________________
>>> Starlink mailing list
>>> Starlink@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/starlink
>> _______________________________________________
>> Starlink mailing list
>> Starlink@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@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] Info on IP country ranges

[Dave Taht]

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.

On Sat, Jan 6, 2024 at 9:59 AM Alexandre Petrescu via Starlink
<starlink@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@lists.bufferbloat.net> wrote:
> >>
> >>
> >>
> >>> Le 13 déc. 2023 à 15:58, David Fernández via Starlink
> >>> <starlink@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@viagenie.ca>
> >>>> To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
> >>>> Cc: Sebastian Moeller <moeller0@gmx.de>, Steven
> >>>> <bufferbloat-lists@steven.honson.au>, starlink@lists.bufferbloat.net
> >>>> Subject: Re: [Starlink] Info on IP country ranges
> >>>> Message-ID: <1FE6B070-C2A0-4C35-8876-33FEDED81F69@viagenie.ca>
> >>>> Content-Type: text/plain;charset=utf-8
> >>>>
> >>>>
> >>>>
> >>>>> Le 13 déc. 2023 à 05:33, Alexandre Petrescu via Starlink
> >>>>> <starlink@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@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@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
> >>
> >> _______________________________________________
> >> Starlink mailing list
> >> Starlink@lists.bufferbloat.net <mailto:Starlink@lists.bufferbloat.net>
> >> https://lists.bufferbloat.net/listinfo/starlink
> >> <https://lists.bufferbloat.net/listinfo/starlink>
> >
> >
> > _______________________________________________
> > Starlink mailing list
> > Starlink@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/starlink
> _______________________________________________
> Starlink mailing list
> Starlink@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

Re: [Starlink] Info on IP country ranges

[Alexandre Petrescu]

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@lists.bufferbloat.net> wrote:
>>
>>
>>
>>> Le 13 déc. 2023 à 15:58, David Fernández via Starlink 
>>> <starlink@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@viagenie.ca>
>>>> To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
>>>> Cc: Sebastian Moeller <moeller0@gmx.de>, Steven
>>>> <bufferbloat-lists@steven.honson.au>, starlink@lists.bufferbloat.net
>>>> Subject: Re: [Starlink] Info on IP country ranges
>>>> Message-ID: <1FE6B070-C2A0-4C35-8876-33FEDED81F69@viagenie.ca>
>>>> Content-Type: text/plain;charset=utf-8
>>>>
>>>>
>>>>
>>>>> Le 13 déc. 2023 à 05:33, Alexandre Petrescu via Starlink
>>>>> <starlink@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@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@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
>>
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net <mailto:Starlink@lists.bufferbloat.net>
>> https://lists.bufferbloat.net/listinfo/starlink 
>> <https://lists.bufferbloat.net/listinfo/starlink>
> 
> 
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] Info on IP country ranges

[Lukasz Bromirski]

[-- Attachment #1: Type: text/plain, Size: 13663 bytes --]


Maybe it's easier/better to "simply" use SSH over SCTP if keeping connection up while changing local gateway IP is requirement?

-- 
./

> On 13 Dec 2023, at 23:57, Marc Blanchet via Starlink <starlink@lists.bufferbloat.net> wrote:
> 
> 
> 
>> Le 13 déc. 2023 à 15:58, David Fernández via Starlink <starlink@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.
> 
> 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@viagenie.ca>
>>> To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
>>> Cc: Sebastian Moeller <moeller0@gmx.de>, Steven
>>> 	<bufferbloat-lists@steven.honson.au>, starlink@lists.bufferbloat.net
>>> Subject: Re: [Starlink] Info on IP country ranges
>>> Message-ID: <1FE6B070-C2A0-4C35-8876-33FEDED81F69@viagenie.ca>
>>> Content-Type: text/plain;	charset=utf-8
>>> 
>>> 
>>> 
>>>> Le 13 déc. 2023 à 05:33, Alexandre Petrescu via Starlink
>>>> <starlink@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@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@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
> 
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net <mailto:Starlink@lists.bufferbloat.net>
> https://lists.bufferbloat.net/listinfo/starlink


[-- Attachment #2: Type: text/html, Size: 19131 bytes --]

Re: [Starlink] Info on IP country ranges

[Marc Blanchet]

[-- Attachment #1: Type: text/plain, Size: 13452 bytes --]



> Le 13 déc. 2023 à 17:57, Marc Blanchet <marc.blanchet@viagenie.ca> a écrit :
> 
> 
> 
>> Le 13 déc. 2023 à 15:58, David Fernández via Starlink <starlink@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@viagenie.ca>
>>> To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
>>> Cc: Sebastian Moeller <moeller0@gmx.de>, Steven
>>> 	<bufferbloat-lists@steven.honson.au>, starlink@lists.bufferbloat.net
>>> Subject: Re: [Starlink] Info on IP country ranges
>>> Message-ID: <1FE6B070-C2A0-4C35-8876-33FEDED81F69@viagenie.ca>
>>> Content-Type: text/plain;	charset=utf-8
>>> 
>>> 
>>> 
>>>> Le 13 déc. 2023 à 05:33, Alexandre Petrescu via Starlink
>>>> <starlink@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@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@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


[-- Attachment #2: Type: text/html, Size: 19461 bytes --]

Re: [Starlink] Info on IP country ranges

[Marc Blanchet]

[-- Attachment #1: Type: text/plain, Size: 12963 bytes --]



> Le 13 déc. 2023 à 15:58, David Fernández via Starlink <starlink@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
moul/quicssh: SSH over QUIC
github.com

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@viagenie.ca>
>> To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
>> Cc: Sebastian Moeller <moeller0@gmx.de>, Steven
>> 	<bufferbloat-lists@steven.honson.au>, starlink@lists.bufferbloat.net
>> Subject: Re: [Starlink] Info on IP country ranges
>> Message-ID: <1FE6B070-C2A0-4C35-8876-33FEDED81F69@viagenie.ca>
>> Content-Type: text/plain;	charset=utf-8
>> 
>> 
>> 
>>> Le 13 déc. 2023 à 05:33, Alexandre Petrescu via Starlink
>>> <starlink@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@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@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


[-- Attachment #2.1: Type: text/html, Size: 15621 bytes --]

[-- Attachment #2.2: quicssh.png --]
[-- Type: image/png, Size: 85430 bytes --]

Re: [Starlink] Info on IP country ranges

[David Fernández]

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? Can you point to an explanation? Thank you!

Regards,

David


> Date: Wed, 13 Dec 2023 09:37:40 -0500
> From: Marc Blanchet <marc.blanchet@viagenie.ca>
> To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
> Cc: Sebastian Moeller <moeller0@gmx.de>, Steven
> 	<bufferbloat-lists@steven.honson.au>, starlink@lists.bufferbloat.net
> Subject: Re: [Starlink] Info on IP country ranges
> Message-ID: <1FE6B070-C2A0-4C35-8876-33FEDED81F69@viagenie.ca>
> Content-Type: text/plain;	charset=utf-8
>
>
>
>> Le 13 déc. 2023 à 05:33, Alexandre Petrescu via Starlink
>> <starlink@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@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@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