From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id BA2C13B2A4 for ; Sat, 6 Jan 2024 10:06:27 -0500 (EST) Received: by mail-pj1-x102d.google.com with SMTP id 98e67ed59e1d1-28bc7155755so234404a91.2 for ; Sat, 06 Jan 2024 07:06:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704553587; x=1705158387; darn=lists.bufferbloat.net; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=qtfDyShMn3v+OAlI81lqrupxVXJiJX/KmfY/qPvc65Q=; b=mULTc9tJLwumIC+HB4ZpF++ApMpm4QLL8zczmJVCvkRVQZ+4CR3+QKv8yZZBvaMutA 0z6Qb1nZcvMdid4+sGll8/RqiobcPapYEwaw2dvUyge8zFVlg7VNntr4ivxZj3T10QGw QZ6d1Zgzbgt0qT4mWFkmwmSppe6ZtCEm6Ka6oKFD6mp5FIo2a6Xb8CYeMtfLst7rgaRn c2bfJN2qrnrn2VBzEiPvHl/JFdgWk5eihMZoxu4KaTojVIZ9sYmd4hIGTw+D+Zg5KMXK wdBN6/v1fOtW/tTHeOqAWlVNqJJ6VeMRInF7DK8rqEJpMmCBAXBZ2ZhTFkTFqeJXKnl2 Zm2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704553587; x=1705158387; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=qtfDyShMn3v+OAlI81lqrupxVXJiJX/KmfY/qPvc65Q=; b=sXVrhdPtjlPr+OEG4W5qgMfFzAEvJUc9uUdeQv++xf3rt92OAxoXWJKWRpJFTHZqCQ E+2kolhUcsCNNDn5O8p2xJP0nH4guqOS0d9e6CGbiP/iTHJ/cxhSGfYyDaHwEztyc0Ct 6C47I55S74cSx+amzhZ9XT+aCe6tqfNiLZoDnugvNc362Ps0v9eOJhamHAfFhfFK+EIT eVrl4Xm8uSwuDKb/A/99idti9805kmKShvLX50A4L34b98hoztIgmFCWXYEF5BdKUNni I0y0ZNuAOqmB0FOFxL+lM73OOaOEP6UvYK+zBzKPLX6oVsTdTn/p3Ej9v4XOV6hc8q0I hxpA== X-Gm-Message-State: AOJu0YyloFIApA6yIvzrm+nyQF5f106br9VYN3r8mZtWd/uhRs6opCB2 ognC821evM+fbCfQwGf+7LwLvVrg8fC15BtWjx4= X-Google-Smtp-Source: AGHT+IEwkFlKEONdMdNhV1T8nm8D/hvXwX6Fd3iSpCUfL0VxHPPx6Op0Qo/tV2nHtWSF2uvDBjXPkHxEd79JFfYdRMk= X-Received: by 2002:a17:90b:1108:b0:28d:2b9d:e273 with SMTP id gi8-20020a17090b110800b0028d2b9de273mr123082pjb.74.1704553586391; Sat, 06 Jan 2024 07:06:26 -0800 (PST) MIME-Version: 1.0 References: <797EE470-B7D6-4A28-81D5-7A283712AB08@viagenie.ca> <0DC55D56-C4AE-4E62-A058-950B08D205E9@bromirski.net> In-Reply-To: From: Dave Taht Date: Sat, 6 Jan 2024 10:06:14 -0500 Message-ID: To: Alexandre Petrescu Cc: starlink@lists.bufferbloat.net Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: Sat, 06 Jan 2024 15:06:27 -0000 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=E2=80=AFAM Alexandre Petrescu via Starlink wrote: > > > > Le 24/12/2023 =C3=A0 02:29, Lukasz Bromirski via Starlink a =C3=A9crit : > > > > 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 mor= e. > > 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 u= p. > > Alex > > > > > -- > > ./ > > > >> On 13 Dec 2023, at 23:57, Marc Blanchet via Starlink > >> wrote: > >> > >> > >> > >>> Le 13 d=C3=A9c. 2023 =C3=A0 15:58, David Fern=C3=A1ndez via Starlink > >>> a =C3=A9crit : > >>> > >>> 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: > >> > >> 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 > >>>> 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 > >>>> > >>>> > >>>> > >>>>> Le 13 d=C3=A9c. 2023 =C3=A0 05:33, Alexandre Petrescu via Starlink > >>>>> a =C3=A9crit : > >>>>> > >>>>> > >>>>> Le 12/12/2023 =C3=A0 11:50, Sebastian Moeller a =C3=A9crit : > >>>>>> Hi Steven, > >>>>>> > >>>>>> > >>>>>> > >>>>>>> On Dec 12, 2023, at 11:33, Steven via Starlink > >>>>>>> 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 visi= ble > >>>>>>> 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 t= he > >>>>>> 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 tunn= el > >>>>>> 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 t= o > >>>>> maintain a constant IP address for a moving end user. > >>>>> > >>>>> Surprisingly, the URL > >>>>> https://support.starlink.com/?topic=3D1192f3ef-2a17-31d9-261a-a59d2= 15629f4 > >>>>> 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 g= oing > >>>> 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 =C3=A0 03:43, Steven a =C3=A9crit : > >>>>>>>>> Thanks for this reference that explicitly states it is IPv6 nat= ive. > >>>>>>>>> > >>>>>>>>> https://support.starlink.com/?topic=3D1192f3ef-2a17-31d9-261a-a= 59d215629f4 > >>>>>>>>> is another Starlink resource that confirms that a /56 is provid= ed. > >>>>>>>>> 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 quest= ions > >>>>>>>> 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 agr= eed > >>>>>>>> that > >>>>>>>> within that core network, that IPv6 is encapsulated in the GTP > >>>>>>>> protocol, > >>>>>>>> which is an UDP/IPv4 protocol. This encapsulation of IPv6 in IPv= 4 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 t= o > >>>>>>>> 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. A= nd > >>>>>>>> starlink users _are_ authenticated and billed, too. Thus, one m= ight > >>>>>>>> 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 mi= ght > >>>>>>>> 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-addre= sses > >>>>>>>>>> "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=E2=80=AFPM Steven Honson via Star= link > >>>>>>>>>> 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 advantageou= s to > >>>>>>>>>>>> use > >>>>>>>>>>>> DHCPv6-PD from a Client in home to starlink Server, and obta= in a > >>>>>>>>>>>> /56. > >>>>>>>>>>>> > >>>>>>>>>>>> But to be native IPv6, it would need the IPv6 packets to tra= vel > >>>>>>>>>>>> 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 ca= n 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 I= Pv6 > >>>>>>>>>>>> latency > >>>>>>>>>>>> is even lower than on IPv4). If the latency reported on IPv= 6 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 =C3=A0 13:24, Steven a =C3=A9crit : > >>>>>>>>>>>>> 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 thes= e > >>>>>>>>>>>>> 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 t= he > >>>>>>>>>>>>> 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 starli= nk > >>>>>>>>>>>>>> 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 allocate= d 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 > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink --=20 40 years of net history, a couple songs: https://www.youtube.com/watch?v=3DD9RGX6QFm5E Dave T=C3=A4ht CSO, LibreQos