From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 272D73CB41 for ; Tue, 12 Dec 2023 05:50:38 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1702378218; x=1702983018; i=moeller0@gmx.de; bh=MTnsO0an196QgPB2E3wZNY5hlrNbvfG2QrJkyTBVgBg=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References: To; b=Ny57o3Q5V9dgTnOV9UGzbxYzCnutxKjE74op4OWbZDGi2rN3hhqeNnDCHQihGjT8 lE1wvxjDk3WkX+WHelIOb455wj0o3C3ewn1xWj/Ij3RwXdpRUck3TGNVB4+vAvP2l UcMcBHzg/vTvPVtDC4EIV8nASlME0r/QaZjvXA9s656rT+UvGd/qVVhIBt2ACHG9l aYc01gCRR6Lt+96WxMBgR0Uzh3XzxXTec/E0AqNQM0umrsmjRbS2ZSDLcQluheNxz B6FAjYRAwyP+Pnj4fi21pyVAhT6ej13BI/YEgb8/pY3IXyKOsxBGEQm8gYmVhU3zN EFClLV5Ezyg6Sfv9kQ== 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 1N5GE1-1rNM59127p-011DPs; Tue, 12 Dec 2023 11:50:18 +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: Tue, 12 Dec 2023 11:50:16 +0100 Cc: Alexandre Petrescu , J Pan , starlink@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: 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> To: Steven X-Mailer: Apple Mail (2.3696.120.41.1.4) X-Provags-ID: V03:K1:d5p4aoZ255+A5LXm5pvg6DFGXuOJ/WsAbgQqYHtFiRpX71ekmpy tBBWeu7gDRluXRAZ39KNt8FfUYr/Tgsw80EZJScnih0HP1bYSU8IchCRinMk/21+MUC9ohw CFB0ZVm9olev8lezQ2xAwZtsoSiXVPe4XlJSuWx+lO6s7NKmC5XNSOdlGgD4hhKx544kdLR NOGcJR8TxZvZfYsFdQD9A== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:b1yjw6uWxZg=;3EvUqo6nxXZzyIPvgu5IRtpE5pn 5sMcKA5sDpN1QyAtrJ5kOyvMgV0LDvpr7Wg6XD5AKJv26eNZ4X95JRcD/TQuJ2fAH7XgRpw5K oQYp6UTQ3hvOg98GJNQuK1DMIbwaOVl+VsNs7sFWVYIow6vzY8WvLz4YQPq+q9NwRWCyUXPqT TUinc2kimPCk2MOXhaL//in/W5cjuJS006S0fPcWzrdnf/jrJ7ZhIVwrakvxfk0F+5Rcc9+D+ 54QoBH3MOQ9K3UpExBVkgx+Ts5BSAyN8+4/Sx1SC00wFOxUJojqB8t92g9ZUmaqvl9cKHwrTV kOYVdaPA+5oWQJkpSVJ1lessSsi9Gv/mL5rp/BUN6AFCvDGe4y3lrEw2CH8U7b0DS1Wy0eK+6 IsOIPwc+YtFPCGNPfelhcHaAG2FMQeAbE0/hfRBZNeWznFUlg/tjw5dOjYjfzGxJ0zfUHEELA vSvzQi3Vn2x/NbHELRErdla7j1lYdZ/Qg3BTdk5Qj+h3PNhfm28QT4FSnkCmgv6DoJbqwpv8z aPUTzrjwx6GQJAhQqYkh1w8NfhSdKN6NXXYbVH8vhMmf1UE1h+VVo4bgfJKvDn70bjhmelBIS HfF45PxARHGf8+ZgY64xtnF9O8MeruB3AKPNP12sUTnMHtjf7nnlLe+KR/FtjpE5LprlnVooc 0VXkCgxsUUD3BAXCKykbrzr18u9MLN+bt/3hezQC1SLITwCIdiT0dkL0k0V9LFJM5EHq+1o3z mlblFg5MVGJfz9BKnhu/ffKQ0F74H0N7MTMlr3uFpg9MU8HA4E+d6IlU/CqhcRFK3Zplmpfuo 73jETrL1K1K+aucsg+Yh3WEzCgxB83dqO1gq4Dn5u/j2my8NfCDNYVWvClKlHnC92bOK7eVUC Ly/wBDun0nX+C8nvLpFxuTZAJkZp8CmsDebq6ECTMzf2kiluT34pDJfeG532auUw+QiSIB92L 8p0r2q6Y7FFaYjuEemKk6wbmjPc= 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:50:39 -0000 Hi Steven, > 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. > 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? Regards Sebastian P.S.: All wild speculation, feel free to ignore ;) >=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. >>=20 >> Thanks for the pointer. It clarifies indeed almost all my questions=20= >> about IPv6 to starlink end users. It is clear about that /56 to end=20= >> users. You also provided confirmation that is with DHCPv6-PD, and = not=20 >> tunnelbroker nor 6to4. This is already very good. >>=20 >> What I further asked (is IPv6 encapsulated in IPv4?) might probably = not=20 >> be within the reach of non-starlink administrators, not visible to=20 >> starlink end users. Sorry for having given the impression that I = might=20 >> doubt the skilfullness. >>=20 >> For example, in 3GPP networks, it is also said, and generally agreed = by=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 = that=20 >> within that core network, that IPv6 is encapsulated in the GTP = protocol,=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. >>=20 >> 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. 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. Still, another role of GTP in 3GPP is=20= >> that of providing a notion of 'circuit', for needs such as AAA: one = such=20 >> 'circuit' is associated to one authenticated and billed user. And=20 >> starlink users _are_ authenticated and billed, too. Thus, one might=20= >> wonder what other than 3GPP's GTP protocol is starlink using to = provide=20 >> that notion of 'circuit'-per-user. Maybe that starlink-circuit = protocol=20 >> is using tunnels, and that tunnel might be an IPv4 tunnel; it might = also=20 >> be an IPv6 tunnel. Maybe it is using MPLS. Maybe something else. >>=20 >> It is worth considering about standards work, interoperability with=20= >> others, a probable NTN-TN convergence, and similar. >>=20 >> Alex >>=20 >>>=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