From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oo1-xc33.google.com (mail-oo1-xc33.google.com [IPv6:2607:f8b0:4864:20::c33]) (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 031ED3CB37 for ; Wed, 13 Dec 2023 09:37:53 -0500 (EST) Received: by mail-oo1-xc33.google.com with SMTP id 006d021491bc7-5908a63a83fso3801211eaf.1 for ; Wed, 13 Dec 2023 06:37:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=viagenie-ca.20230601.gappssmtp.com; s=20230601; t=1702478273; x=1703083073; darn=lists.bufferbloat.net; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=FsDcGZBK60Z6265vfrF1YWcbkl60z4P6cyTsBRBwecY=; b=Jm9DNrx/cVRqFxW0HQg7godPRQf5ODNKI3DL5rGddiBWZU3IIM5wXFrlMX4HSYJjfO 1eakJiUK/A23YNZm0S8d5mjbInYHZskBmhv5Agk2ZDKQAfELXBsXwScnoe/3/clQXI9T AbwJTlWwwmXn3PXyrjJu77u59Zdlvd79tLZDjOz7xoPYd6EdacNuaWJ0gBxe3yM66iCI Ngmle8mePSwN9P19SRCPYV8ss+PtCBG1v+G64yHlP89Te+qAcOW4tuvmLJ+H/i/QlmxW vixXI/qvAcFtAvURybPfpNCHIBbOyigbfpUG0x25Yq2YzNIYCSDhupy+M62lzU8D39j7 kFxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702478273; x=1703083073; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=FsDcGZBK60Z6265vfrF1YWcbkl60z4P6cyTsBRBwecY=; b=ACnCHKCf9nqQXIYhc4OkLaqulIFmUWkcpwjrHmrb/73EiaY7E1hSCrx3FJH/+eFniW vE67fGaHHPr7VMELj2O+9ApI/mLrKpMUm7XquEI3Zuts3BRaIhBX2dE8V5LDgI2y4sOK mepge9w/u93BSIM7FdkQb8LHtv17ueXCbadj2DHYk7ZB5YKOez1WCdK1YRHYegOf9J5u yIBcBaZoFOo5SeC57ilouJY2zLn2ujYg5O00wCqCT3ZC7ced99ujnMB/YXXgaTURnnZt nTwlnh5JRa6pV/gWcOXk1Vj0bq0q8SyFm7g7FV8GEKhgTl6O+o3yN8Z3qD6K/H451qNz 4WFg== X-Gm-Message-State: AOJu0Ywyl4JykaR+Xc9MJ1qpypCJMdOH2u6khGbPNebCBldBn0IjSXq1 gg/e0RurxEp2r38FbloAwBByjA== X-Google-Smtp-Source: AGHT+IGiE6jvT0uT++nJ8yiv9ZeGndEz7RTp2QmblmEF7Bgz2bJDU8oCJunSMg0rq0/79DuebRmoWA== X-Received: by 2002:a05:6358:419d:b0:170:4168:8b91 with SMTP id w29-20020a056358419d00b0017041688b91mr10410418rwc.24.1702478272924; Wed, 13 Dec 2023 06:37:52 -0800 (PST) Received: from smtpclient.apple (modemcable161.124-162-184.mc.videotron.ca. [184.162.124.161]) by smtp.gmail.com with ESMTPSA id c10-20020a0ceb4a000000b0067a27108513sm5038715qvq.67.2023.12.13.06.37.51 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Dec 2023 06:37:51 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\)) From: Marc Blanchet In-Reply-To: Date: Wed, 13 Dec 2023 09:37:40 -0500 Cc: Sebastian Moeller , Steven , starlink@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <1FE6B070-C2A0-4C35-8876-33FEDED81F69@viagenie.ca> References: <361ee9d0d01da491a6e2b132317d170b@ausics.net> <924492fc-6ce4-4e62-82d9-c8f0b50ee96d@gmail.com> <8a807397-edef-4dcc-bfa6-f9c1598cbc77@gmail.com> <69da68cf-8746-45f8-9537-8fd8252de115@gmail.com> <7a20ea4f-4f16-4584-9f53-1ee3c72afd6f@app.fastmail.com> <26abce66-300f-405e-ad18-cc32695580fa@gmail.com> <4d0cd8c6-9de7-4976-8d46-ef159ea06c58@gmail.com> <21b2df7e-23c6-4c84-980f-635f41483c29@app.fastmail.com> <19c3c701-7c1a-4f04-a35f-bbec3055a54b@app.fastmail.com> <9d67c201-e759-4730-aa0c-e1c1a7186f84@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3774.200.91.1.1) 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: Wed, 13 Dec 2023 14:37:54 -0000 > 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. I would be very (happily) surprised if they do support that. >=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). 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 > 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 >>> _______________________________________________ >>> 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