From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 5F5353CB41 for ; Tue, 12 Dec 2023 05:33:36 -0500 (EST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 400AE5C02CE; Tue, 12 Dec 2023 05:33:35 -0500 (EST) Received: from imap43 ([10.202.2.93]) by compute3.internal (MEProxy); Tue, 12 Dec 2023 05:33:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=honson.au; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1702377215; x=1702463615; bh=iog8ynVJDYXrG6PAS9S+pUpa/2gtYedolJtdOjkVbDI=; b= FkrWiHZbxpf28341V/+QMVJ8UmtDb5fzBENYrUwy78FR8/jJtxS4LexbHQxnDgzP E3nWqszf7XsSgjeoMI7zQJL5HN1OD63AuDdxzn9xBx5l13gNJeycMSzw8T9tDz4A VD8/YgvM4KNQTYNaGfrzK+3cOXuJEXNM5pxCVRnsi+3x7nW7dtfsXGBXRZOCzMSo gZf9akUSUhS4HCZ2/ACbEVkxORj+I6t6Hdq/Em1ERAptcWSuXGtIzuTS6CWanwD9 MuP1rWcyp1iF9sOu+tnQTm4Ghj7a8h2g82hzbM7hMYm8jQBczVha01fTlbR2+TBs WYMmh0L4f42Qe1QeHM4x/g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1702377215; x= 1702463615; bh=iog8ynVJDYXrG6PAS9S+pUpa/2gtYedolJtdOjkVbDI=; b=i +/T/eZMZ5BTzTeyeiUAv88uE22fW1jQ92cPZi+Pne1jkEBWnSaSu7Dr7OhKEeS6l eaDzu2y5LexfRQwDCMoDk3CHIsalmcrKIML2Cg2fVCvHCFftxdBaso4CZvQeANu0 kiRB8utYNR2qbs08FP7brxexoBWZgWdaKiAwSf3fO2TAE3U057FbMNruHM/AmmSF P6lsCzvyNuW2GvxFivV70+PTBVn/1EHGlI2V1JzYwooFyErMfXi01josy8GmjpKE MVV1142NEvNn4ENIQFUoo12rNQSg/ZXy9FwD6NTPiV6RxZ1dpA8iB3gUFhfXaIw3 sHgZps9PoSH/S1xMoc2Mg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudelgedgudeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtgfesthhqredtreerjeenucfhrhhomhepufht vghvvghnuceosghufhhfvghrsghlohgrthdqlhhishhtshesshhtvghvvghnrdhhohhnsh honhdrrghuqeenucggtffrrghtthgvrhhnpefhjedvkedugeekteehheetveehveegtefh ffffvddujeelvdeuveefhfeggeelffenucffohhmrghinhepshhtrghrlhhinhhkrdgtoh hmpdhrvggrughmvgdrihhopdhuvhhitgdrtggrpdhsphgvvgguthgvshhtrdhnvghtpdgs uhhffhgvrhgslhhorghtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomhepsghufhhfvghrsghlohgrthdqlhhishhtshesshhtvghvvghn rdhhohhnshhonhdrrghu X-ME-Proxy: Feedback-ID: iaed446c2:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id CFCF42D4007D; Tue, 12 Dec 2023 05:33:34 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-1283-g327e3ec917-fm-20231207.002-g327e3ec9 MIME-Version: 1.0 Message-Id: In-Reply-To: <9d67c201-e759-4730-aa0c-e1c1a7186f84@gmail.com> References: <361ee9d0d01da491a6e2b132317d170b@ausics.net> <75790520d6c8d35beb7248f5f5dff952@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> Date: Tue, 12 Dec 2023 21:33:14 +1100 From: Steven To: "Alexandre Petrescu" , "J Pan" 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: Tue, 12 Dec 2023 10:33:36 -0000 Hi Alex, Thank you for the further detail, my apologies if I misunderstand your l= ine of inquiry. I had interpreted it to mean that you were still not con= vinced it was native from the perspective of the end-user visible compon= ents. You are right that there may be some IPv6-in-IPv4 encapsulation occurrin= g within the Starlink network that is undetectable to end-users. That sa= id 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. 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 a= ppear to be having a noticeable performance impact. 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=C2=A0: >> Thanks for this reference that explicitly states it is IPv6 native. >> >> https://support.starlink.com/?topic=3D1192f3ef-2a17-31d9-261a-a59d215= 629f4 is another Starlink resource that confirms that a /56 is provided.= This one doesn't explicitly mention native, but as mentioned I am confi= dent it is. > > Thanks for the pointer.=C2=A0 It clarifies indeed almost all my questi= ons=20 > about IPv6 to starlink end users.=C2=A0 It is clear about that /56 to = end=20 > users.=C2=A0 You also provided confirmation that is with DHCPv6-PD, an= d not=20 > tunnelbroker nor 6to4.=C2=A0 This is already very good. > > What I further asked (is IPv6 encapsulated in IPv4?) might probably no= t=20 > be within the reach of non-starlink administrators, not visible to=20 > starlink end users.=C2=A0 Sorry for having given the impression that I= might=20 > doubt the skilfullness. > > For example, in 3GPP networks, it is also said, and generally agreed b= y=20 > very skilled persons, that almost all IPv6 is provided as native IPv6.=20 > In that context, it means that the packets from smartphone to a core=20 > network entity are not encapsulated in IPv4. But, it is also agreed th= at=20 > within that core network, that IPv6 is encapsulated in the GTP protoco= l,=20 > which is an UDP/IPv4 protocol. This encapsulation of IPv6 in IPv4 is=20 > invisible to end users, even if the encapsulation is there. > > For 3GPP, the use of GTP is very much dedicated to supporting mobility= -=20 > a user keeps a same IP address while changing base stations and S-GWs = or=20 > SGSNs.=C2=A0 In starlink, on the contrary, it is probably not the case= that=20 > the GTP protocol is used for mobility (I dont know?), because starlink=20 > says that the IP address might change during mobility (that URL you=20 > point to says "Our system is dynamic where moving the Starlink to=20 > another location [...] may cause the public IP to change."); so maybe=20 > IPv6 is not encapped in UDPv4.=C2=A0 Still, another role of GTP in 3GP= P is=20 > that of providing a notion of 'circuit', for needs such as AAA: one su= ch=20 > 'circuit' is associated to one authenticated and billed user.=C2=A0 An= d=20 > starlink users _are_ authenticated and billed, too.=C2=A0 Thus, one mi= ght=20 > wonder what other than 3GPP's GTP protocol is starlink using to provid= e=20 > that notion of 'circuit'-per-user.=C2=A0 Maybe that starlink-circuit p= rotocol=20 > is using tunnels, and that tunnel might be an IPv4 tunnel; it might al= so=20 > be an IPv6 tunnel.=C2=A0 Maybe it is using MPLS. Maybe something else. > > It is=C2=A0 worth considering about standards work, interoperability w= ith=20 > 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-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 >>> >>> On Mon, Dec 11, 2023 at 5:10=E2=80=AFPM Steven Honson via Starlink >>> wrote: >>>> Hi Alex, >>>> >>>> As an experienced network engineer with extensive experience with I= Pv6, 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 advantageous to u= se >>>>> DHCPv6-PD from a Client in home to starlink Server, and obtain a /= 56. >>>>> >>>>> But to be native IPv6, it would need the IPv6 packets to travel na= tively >>>>> (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 c= lient >>>>> vs from an IPv6-only client. An IPv6-only Windows client can be m= ade by >>>>> unchecking the IPv4 box in interface Properties window. >>>>> >>>>> Ideally, if it is IPv6 native, the latency reported by speedtest.n= et is >>>>> approximatively the same on IPv4 vs on IPv6 (sometimes the IPv6 la= tency >>>>> is even lower than on IPv4). If the latency reported on IPv6 is h= igher >>>>> than on IPv4 it could be for many reasons, and one of them could b= e that >>>>> IPv6 is not native, but encapsulated in IPv4. The IPv4 encapsulat= ing >>>>> 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 del= egate 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 D= HCPv6-PD >>>>>>> local server config files. >>>>>> I am confident this is not the case since I configured these rout= ers 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 the DHC= Pv6 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 starlin= k ground >>>>>>> network: maybe on the teleport, maybe deeper on the starlink net= work. >>>>>> 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 on= e as my default gateway (`2406:2d40:xxx:xxx::1`). The /56 I am being all= ocated is also from the same /32 as this DHCPv6 server, with the /32 bei= ng 2406:2d40::/32, which you'll note is allocated to Starlink. >>>>>> >>>>>> Cheers, >>>>>> Steven >>>> _______________________________________________ >>>> Starlink mailing list >>>> Starlink@lists.bufferbloat.net >>>> https://lists.bufferbloat.net/listinfo/starlink