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