From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 6B2823B29D for ; Mon, 8 Jan 2024 05:54:29 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1704711267; x=1705316067; i=moeller0@gmx.de; bh=xxg8kNcjIn3KVJ3Eliw+PafLkltPYuwivd8JPpVwkxA=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References: To; b=fO6u7JQ4s1WOgKNmRwDB1DR5dOHlDnjz3Oat7mDy8HlDnPM6Ibsg3cc3gPzL3Zlr cWWAqI332COBxtr1x/zZjLoHohKXFczPCM/MlT2CEzrHvSeRCaLYyAXS25rV4qgxR uC4i8EVOEL0nk8TfTOWoUSfAMPAD7ZjL6lWSt13UROkBvbvXkdOjO4Px2lKwXp57z T2z5aEKX1bGroki1uqK6niOe7/WAkhat1CaGzhFXLNEaGZNLE15Mw6i52OtRIYjp6 GI/i7Ktwe+TEFlla+K4JydpCKH+nVqaLWTtvH/zIdmkIaMsHHIYnQ7X5a0KmRgich qi0gNmHFAdE2CdzZ2w== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([134.76.241.253]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MQvD5-1raBGO0eNb-00O0lu; Mon, 08 Jan 2024 11:54:27 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.4\)) From: Sebastian Moeller In-Reply-To: Date: Mon, 8 Jan 2024 11:54:26 +0100 Cc: Alexandre Petrescu , starlink@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <8D9F47C8-866B-4CDB-8B17-CE93EEFF8498@gmx.de> References: <797EE470-B7D6-4A28-81D5-7A283712AB08@viagenie.ca> <0DC55D56-C4AE-4E62-A058-950B08D205E9@bromirski.net> To: =?utf-8?Q?Dave_T=C3=A4ht?= X-Mailer: Apple Mail (2.3696.120.41.1.4) X-Provags-ID: V03:K1:2OAjYw52G0hI1GHzOXgvaNIvd3W+x/pq+jKB1xEqnJP+J041ISg DbCSc16/QIxRal711OyaJnW/bMgQeXZw77/p5Y+c/q9iumt7R+eutNW41Jg1e8pA9lTQrLF uuw6OAbUCpO5WqMXhiTlEci98j5e9YAVyAwbz6dFg3MCgDAwsQRCMIOqRruFJGC9Dik0hxj 0rJuJL2c6T651XGfdR+1w== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:Bwf5sQCV1XI=;3qomQc0j4e4CrDaToHxJ4VnXFPL 5g8MWoRmR+nc+j8kDaKt3mnRyKVALXn04olf84GO+LCko5zkSD9nPoqiDbfHGmAu86F1ysWFf ihadQDRg6paYh+hRYekZKqybnEH4CItCfgs7zoqj2eVb0HYNod9IGWvHHtf3sQ4AO8/AeXtyC G0D27CD6wEGX9gK+xxRjce+DrAJv7cqdfYkBje5X3xhVcUR3bqKab+W/KYDmBHbVqmc8NEqyg /RXG1D5xKPTympzw7tY8DFqAtn7UXlc34E+e+78+qkBPYCE8JMnNRVzgbHS0fThh5mpnUErzU HuEh6AJKf5HdPdyCOjc3lYfj2/IqCf7lC/RE8fknN3W0u8Uj9FGkFk4qBKXOfZbWEyD+tiVnl r+PWdcfHvBumHkYwSUyFwutj2TarKPsZiZCqjBzUhJqdlsr3VpHLD1xBnnMeblaDG21Oz0D/C 6Hb4foWlgnnHORyIlaFoZJk0KrvbmIDri+ZOpjFUcwCTbIpDfejJ32WQYiL6uDTXDJq/9jl9K +lxmm2r+PhfS1cJgA9aR5nUElTXQwj5KggA8EpAT0bDFrdyRp5O+O3qZUxQkTdgyyjtAtgGvV NgiYI2OMGH32WP/2HljidYl6UBWTbc+Q/qZ5Ec/D96CRZWX4TWD+Bt6il92UJaBO1dhjXxW4G QISvxPvCpQwSBVK+/z+XLVsWyUIAy6JBw9dGF8ZjOKSMUBfcDZnen0XOnru+3S36euonGIcPP UlAXNGEcB6aLV8fNN64qJTCVd+NXuMg/Hef8JE0Z73YR3FZ1GUOk/1zQCpuMTWQguZLKhPOgC Fh43XYq+BjR0f/hSicrUWQZITzoE4dRL/4WMumNaCZL9sDOr7LXAM9dQlG+LrlyQuwbuTFCDT edQmEax13XVe8oobBESGDrn8OUXSW5JoAkY3RlCz808rx7kzo+HMf4meg1AX+OgV5ZXr6RtuW R/44CjCdiuHBWqJwkuaA29YhfPo= Subject: Re: [Starlink] Info on IP country ranges X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2024 10:54:30 -0000 > On Jan 6, 2024, at 16:06, Dave Taht via Starlink = wrote: >=20 > 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". >=20 > 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... >=20 > On Sat, Jan 6, 2024 at 9:59=E2=80=AFAM Alexandre Petrescu via Starlink > wrote: >>=20 >>=20 >>=20 >> Le 24/12/2023 =C3=A0 02:29, Lukasz Bromirski via Starlink a =C3=A9crit = : >>>=20 >>> Maybe it's easier/better to "simply" use SSH over SCTP if keeping >>> connection up while changing local gateway IP is requirement? >>=20 >> 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. >>=20 >> 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. >>=20 >> SSH over QUIC might work even better. >>=20 >> But there can be more to it than that. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> Alex >>=20 >>>=20 >>> -- >>> ./ >>>=20 >>>> On 13 Dec 2023, at 23:57, Marc Blanchet via Starlink >>>> wrote: >>>>=20 >>>>=20 >>>>=20 >>>>> Le 13 d=C3=A9c. 2023 =C3=A0 15:58, David Fern=C3=A1ndez via = Starlink >>>>> a =C3=A9crit : >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> 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." >>>>>=20 >>>>> What is that way? >>>>=20 >>>> 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: >>>> >>>> moul/quicssh: SSH over QUIC >>>> github.com >>>>=20 >>>> >>>>=20 >>>> 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. >>>>=20 >>>> Marc. >>>>=20 >>>>> Can you point to an explanation? Thank you! >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> David >>>>>=20 >>>>>=20 >>>>>> Date: Wed, 13 Dec 2023 09:37:40 -0500 >>>>>> From: Marc Blanchet >>>>>> To: Alexandre Petrescu >>>>>> Cc: Sebastian Moeller , Steven >>>>>> , = 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=3Dutf-8 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> Le 13 d=C3=A9c. 2023 =C3=A0 05:33, Alexandre Petrescu via = Starlink >>>>>>> a =C3=A9crit : >>>>>>>=20 >>>>>>>=20 >>>>>>> Le 12/12/2023 =C3=A0 11:50, Sebastian Moeller a =C3=A9crit : >>>>>>>> Hi Steven, >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> On Dec 12, 2023, at 11:33, Steven via Starlink >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>> Hi Alex, >>>>>>>>>=20 >>>>>>>>> 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. >>>>>>>>>=20 >>>>>>>>> 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. >>>>>>>>=20 >>>>>>>>> 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? >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> There is also the mobility aspect of the tunnels. >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> Surprisingly, the URL >>>>>>> = https://support.starlink.com/?topic=3D1192f3ef-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. >>>>>>>=20 >>>>>>> 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. >>>>>>=20 >>>>>> I would be very (happily) surprised if they do support that. >>>>>>=20 >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> (this mobility aspect is on topic of the IP country ranges - >>>>>>> cross-border >>>>>>> areas would ideally not break connectivity). >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> Marc. >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> Alex >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Regards >>>>>>>> Sebastian >>>>>>>>=20 >>>>>>>> P.S.: All wild speculation, feel free to ignore ;) >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> Regards, >>>>>>>>> Steven >>>>>>>>>=20 >>>>>>>>> On Tue, 12 Dec 2023, at 9:22 PM, Alexandre Petrescu wrote: >>>>>>>>>> Le 12/12/2023 =C3=A0 03:43, Steven a =C3=A9crit : >>>>>>>>>>> Thanks for this reference that explicitly states it is IPv6 = native. >>>>>>>>>>>=20 >>>>>>>>>>> = https://support.starlink.com/?topic=3D1192f3ef-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. >>>>>>>>>>=20 >>>>>>>>>> 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. >>>>>>>>>>=20 >>>>>>>>>> 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. >>>>>>>>>>=20 >>>>>>>>>> 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. >>>>>>>>>>=20 >>>>>>>>>> It is worth considering about standards work, = interoperability with >>>>>>>>>> others, a probable NTN-TN convergence, and similar. >>>>>>>>>>=20 >>>>>>>>>> Alex >>>>>>>>>>=20 >>>>>>>>>>> Cheers, >>>>>>>>>>> Steven >>>>>>>>>>>=20 >>>>>>>>>>> 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 >>>>>>>>>>>>=20 >>>>>>>>>>>> On Mon, Dec 11, 2023 at 5:10=E2=80=AFPM Steven Honson via = Starlink >>>>>>>>>>>> wrote: >>>>>>>>>>>>> Hi Alex, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> As an experienced network engineer with extensive = experience with >>>>>>>>>>>>> IPv6, I'm confident this is native IPv6. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Cheers, >>>>>>>>>>>>> Steven >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Tue, 12 Dec 2023, at 2:30 AM, Alexandre Petrescu wrote: >>>>>>>>>>>>>> Steven, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Alex >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Le 08/12/2023 =C3=A0 13:24, Steven a =C3=A9crit : >>>>>>>>>>>>>>> Alexandre, >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> 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... >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>> Steven >>>>> _______________________________________________ >>>>> Starlink mailing list >>>>> Starlink@lists.bufferbloat.net >>>>> https://lists.bufferbloat.net/listinfo/starlink >>>>=20 >>>> _______________________________________________ >>>> Starlink mailing list >>>> Starlink@lists.bufferbloat.net = >>>> https://lists.bufferbloat.net/listinfo/starlink >>>> >>>=20 >>>=20 >>> _______________________________________________ >>> 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 >=20 >=20 >=20 > --=20 > 40 years of net history, a couple songs: > https://www.youtube.com/watch?v=3DD9RGX6QFm5E > Dave T=C3=A4ht CSO, LibreQos > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink