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), p...@uvic.ca, >> 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> >> >> >> >> 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
