<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><br id="lineBreakAtBeginningOfMessage"><div><br><blockquote type="cite"><div>Le 13 déc. 2023 à 17:57, Marc Blanchet <marc.blanchet@viagenie.ca> a écrit :</div><br class="Apple-interchange-newline"><div><meta charset="UTF-8"><br class="Apple-interchange-newline"><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><blockquote type="cite" style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><div>Le 13 déc. 2023 à 15:58, David Fernández via Starlink <starlink@lists.bufferbloat.net> a écrit :</div><br class="Apple-interchange-newline"><div><div>Hi,<br><br>About this:<br>"There is even a way to do standard ssh (aka over TCP) over QUIC (a<br>bit clunky but works) to keep the ssh connection going while changing<br>IP addresses."<br><br>What is that way?</div></div></blockquote><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><br></div><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">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:</div><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><div style="display: block;"><div class="apple-rich-link" draggable="true" role="link" data-url="https://github.com/moul/quicssh" style="-webkit-user-select: all; -webkit-user-drag: element; display: inline-block;"><a class="lp-rich-link" rel="nofollow" href="https://github.com/moul/quicssh" dir="ltr" role="button" draggable="false" width="300" style="border-radius: 10px; font-family: -apple-system, Helvetica, Arial, sans-serif; display: block; -webkit-user-select: none; width: 300px; -webkit-user-modify: read-only; overflow: hidden; text-decoration: none;"><table class="lp-rich-link-emailBaseTable" cellpadding="0" cellspacing="0" border="0" width="300" style="table-layout: fixed; border-collapse: collapse; width: 300px; background-color: rgb(229, 230, 233); font-family: -apple-system, Helvetica, Arial, sans-serif;"><tbody><tr><td vertical-align="center" align="center"><span id="cid:AD41C9BA-C267-452F-9577-B0A2E59AB8EC"><quicssh.png></span></td></tr><tr><td vertical-align="center"><table bgcolor="#E5E6E9" cellpadding="0" cellspacing="0" width="300" class="lp-rich-link-captionBar" style="font-family: -apple-system, Helvetica, Arial, sans-serif; table-layout: fixed; background-color: rgb(229, 230, 233);"><tbody><tr><td class="lp-rich-link-captionBar-textStackItem" style="padding: 8px 0px;"><div class="lp-rich-link-captionBar-textStack" style="max-width: 100%; margin: 0px 16px; overflow: hidden;"><div class="lp-rich-link-captionBar-textStack-topCaption-leading" style="overflow-wrap: break-word; font-weight: 500; font-size: 12px; overflow: hidden; text-overflow: ellipsis; text-align: left;"><a rel="nofollow" href="https://github.com/moul/quicssh" draggable="false" style="text-decoration: none;"><font color="#272727" style="">moul/quicssh: SSH over QUIC</font></a></div><div class="lp-rich-link-captionBar-textStack-bottomCaption-leading" style="overflow-wrap: break-word; font-weight: 400; font-size: 11px; overflow: hidden; text-overflow: ellipsis; text-align: left;"><a rel="nofollow" href="https://github.com/moul/quicssh" draggable="false" style="text-decoration: none;"><font color="#808080" style="">github.com</font></a></div></div></td></tr></tbody></table></td></tr></tbody></table></a></div></div><br></div><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">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.</div></div></blockquote><div><br></div><div>I should add that someone wrote a draft on SSH over QUIC natively (draft-bider-ssh-quic) but seems dead and no implementation known </div><div><br></div><div>Marc.</div><br><blockquote type="cite"><div><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><br></div><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">Marc.</div><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"></div><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><blockquote type="cite" style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><div><div>Can you point to an explanation? Thank you!<br><br>Regards,<br><br>David<br><br><br><blockquote type="cite">Date: Wed, 13 Dec 2023 09:37:40 -0500<br>From: Marc Blanchet <marc.blanchet@viagenie.ca><br>To: Alexandre Petrescu <alexandre.petrescu@gmail.com><br>Cc: Sebastian Moeller <moeller0@gmx.de>, Steven<br><span class="Apple-tab-span" style="white-space: pre;"> </span><bufferbloat-lists@steven.honson.au>, starlink@lists.bufferbloat.net<br>Subject: Re: [Starlink] Info on IP country ranges<br>Message-ID: <1FE6B070-C2A0-4C35-8876-33FEDED81F69@viagenie.ca><br>Content-Type: text/plain;<span class="Apple-tab-span" style="white-space: pre;"> </span>charset=utf-8<br><br><br><br><blockquote type="cite">Le 13 déc. 2023 à 05:33, Alexandre Petrescu via Starlink<br><starlink@lists.bufferbloat.net> a écrit :<br><br><br>Le 12/12/2023 à 11:50, Sebastian Moeller a écrit :<br><blockquote type="cite">Hi Steven,<br><br><br><br><blockquote type="cite">On Dec 12, 2023, at 11:33, Steven via Starlink<br><starlink@lists.bufferbloat.net> wrote:<br><br>Hi Alex,<br><br>Thank you for the further detail, my apologies if I misunderstand your<br>line of inquiry. I had interpreted it to mean that you were still not<br>convinced it was native from the perspective of the end-user visible<br>components.<br><br>You are right that there may be some IPv6-in-IPv4 encapsulation<br>occurring within the Starlink network that is undetectable to end-users.<br>That said I would be surprised if that was the case but as you highlight<br>can't say conclusively, not having inside knowledge as to their<br>architecture.<br></blockquote><span class="Apple-tab-span" style="white-space: pre;"> </span>One easy thing to check would be MTU/MSS to arbitrary internet end<br>points, as any encapsulation typically takes up some space and not every<br>operator id courteous enough to enlarge the tunnel MTU such that the<br>inner internet visible effective MTU is 1500 bytes. Sure, not a guarantee<br>but at least an easy to check hint.<br><br><blockquote type="cite">If it helps, the latency and throughput I have measured of IPv4 vs IPv6<br>on Starlink is comparable, so if encapsulation is occurring it doesn't<br>appear to be having a noticeable performance impact.<br></blockquote><span class="Apple-tab-span" style="white-space: pre;"> </span>Or both IPv6 and Iv4 user packets go through the same type of tunnel<br>set-up to get to their home-base station?<br></blockquote><br>Indeed, if tunnelling is used within the starlink network (like GTP a 3GPP<br>network) that would presumably encapsulate both IPv4 and IPv6. A tunnel<br>elimination technique within the starlink network would presumably reduce<br>the latency both of IPv4 user packets and of IPv6 user packets.<br><br>There is also the mobility aspect of the tunnels.<br><br>A tunnel within 3GPP network (GTP) is used, among other reasons, to<br>support mobility. The 'mobility', among some interpretations, is to<br>maintain a constant IP address for a moving end user.<br><br>Surprisingly, the URL<br>https://support.starlink.com/?topic=1192f3ef-2a17-31d9-261a-a59d215629f4<br>explains that that kind of mobility is not supported in starlink, i.e. the<br>end user might get another IP address if going to some other area. It is<br>surprising in that in other starlink.com URLs they offer starlink service<br>for automobiles, and these typically move a lot. Maybe the<br>starlink-connected automobiles do change their IP addresses a lot, but the<br>end users dont care that much.<br><br>To support mobility within a starlink network - maintain constant all IP<br>addresses in a car - maybe one would try the DHCPv6 CONFIRM message to try<br>to maintain the same allocated /56 but it another area. Maybe the<br>starlink DHCPv6-PD server will satisfy that CONFIRM, or maybe not.<br></blockquote><br>I would be very (happily) surprised if they do support that.<br><br><blockquote type="cite"><br>Or maybe there is a need of some other protocol in starlink, or in user<br>equipment connected to starlink (Dishy, third party router), to offer that<br>mobility. But without adding new latency, of course.<br><br>(this mobility aspect is on topic of the IP country ranges - cross-border<br>areas would ideally not break connectivity).<br></blockquote><br>That problem (IP address stability to keep connection going) is fading away,<br>because the QUIC transport does re-establish connections for you<br>automatically. So as every day passes that QUIC is getting more and more<br>deployed and used (now counting for >30% of traffic), that mobility problem<br>goes away. Yes, not all protocols have been carried over to QUIC, but it is<br>in the process for many. There is even a way to do standard ssh (aka over<br>TCP) over QUIC (a bit clunky but works) to keep the ssh connection going<br>while changing IP addresses.<br><br>Marc.<br><br><br><blockquote type="cite"><br>Alex<br><br><blockquote type="cite"><br>Regards<br><span class="Apple-tab-span" style="white-space: pre;"> </span>Sebastian<br><br>P.S.: All wild speculation, feel free to ignore ;)<br><br><br><blockquote type="cite">Regards,<br>Steven<br><br>On Tue, 12 Dec 2023, at 9:22 PM, Alexandre Petrescu wrote:<br><blockquote type="cite">Le 12/12/2023 à 03:43, Steven a écrit :<br><blockquote type="cite">Thanks for this reference that explicitly states it is IPv6 native.<br><br>https://support.starlink.com/?topic=1192f3ef-2a17-31d9-261a-a59d215629f4<br>is another Starlink resource that confirms that a /56 is provided.<br>This one doesn't explicitly mention native, but as mentioned I am<br>confident it is.<br></blockquote>Thanks for the pointer. It clarifies indeed almost all my questions<br>about IPv6 to starlink end users. It is clear about that /56 to end<br>users. You also provided confirmation that is with DHCPv6-PD, and not<br>tunnelbroker nor 6to4. This is already very good.<br><br>What I further asked (is IPv6 encapsulated in IPv4?) might probably not<br>be within the reach of non-starlink administrators, not visible to<br>starlink end users. Sorry for having given the impression that I might<br>doubt the skilfullness.<br><br>For example, in 3GPP networks, it is also said, and generally agreed by<br>very skilled persons, that almost all IPv6 is provided as native IPv6.<br>In that context, it means that the packets from smartphone to a core<br>network entity are not encapsulated in IPv4. But, it is also agreed<br>that<br>within that core network, that IPv6 is encapsulated in the GTP<br>protocol,<br>which is an UDP/IPv4 protocol. This encapsulation of IPv6 in IPv4 is<br>invisible to end users, even if the encapsulation is there.<br><br>For 3GPP, the use of GTP is very much dedicated to supporting mobility<br>-<br>a user keeps a same IP address while changing base stations and S-GWs<br>or<br>SGSNs. In starlink, on the contrary, it is probably not the case that<br>the GTP protocol is used for mobility (I dont know?), because starlink<br>says that the IP address might change during mobility (that URL you<br>point to says "Our system is dynamic where moving the Starlink to<br>another location [...] may cause the public IP to change."); so maybe<br>IPv6 is not encapped in UDPv4. Still, another role of GTP in 3GPP is<br>that of providing a notion of 'circuit', for needs such as AAA: one<br>such<br>'circuit' is associated to one authenticated and billed user. And<br>starlink users _are_ authenticated and billed, too. Thus, one might<br>wonder what other than 3GPP's GTP protocol is starlink using to provide<br>that notion of 'circuit'-per-user. Maybe that starlink-circuit<br>protocol<br>is using tunnels, and that tunnel might be an IPv4 tunnel; it might<br>also<br>be an IPv6 tunnel. Maybe it is using MPLS. Maybe something else.<br><br>It is worth considering about standards work, interoperability with<br>others, a probable NTN-TN convergence, and similar.<br><br>Alex<br><br><blockquote type="cite">Cheers,<br>Steven<br><br>On Tue, 12 Dec 2023, at 1:29 PM, J Pan wrote:<br><blockquote type="cite">yes. https://starlink-enterprise-guide.readme.io/docs/ip-addresses<br>"Starlink is IPv6 native network. Using IPv6 is more flexible and<br>future-proof." starlink has greatly improved tech docs<br>--<br>J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA,<br>Web.UVic.CA/~pan<br><br>On Mon, Dec 11, 2023 at 5:10 PM Steven Honson via Starlink<br><starlink@lists.bufferbloat.net> wrote:<br><blockquote type="cite">Hi Alex,<br><br>As an experienced network engineer with extensive experience with<br>IPv6, I'm confident this is native IPv6.<br><br>Cheers,<br>Steven<br><br>On Tue, 12 Dec 2023, at 2:30 AM, Alexandre Petrescu wrote:<br><blockquote type="cite">Steven,<br><br>Thanks for the clarifications. It is indeed very advantageous to<br>use<br>DHCPv6-PD from a Client in home to starlink Server, and obtain a<br>/56.<br><br>But to be native IPv6, it would need the IPv6 packets to travel<br>natively<br>(sit directly on the link layer) between home and starlink network.<br>If<br>these IPv6 packets are encapsulate in IPv4, then there would be a<br>risk<br>of additional latency compared to v4.<br><br>A possible way to find out whether it's IPv6 native (and hence no<br>additional latency) is to browse speedtest.net from an IPv4-only<br>client<br>vs from an IPv6-only client. An IPv6-only Windows client can be<br>made by<br>unchecking the IPv4 box in interface Properties window.<br><br>Ideally, if it is IPv6 native, the latency reported by<br>speedtest.net is<br>approximatively the same on IPv4 vs on IPv6 (sometimes the IPv6<br>latency<br>is even lower than on IPv4). If the latency reported on IPv6 is<br>higher<br>than on IPv4 it could be for many reasons, and one of them could be<br>that<br>IPv6 is not native, but encapsulated in IPv4. The IPv4<br>encapsulating<br>endpoint could be on Dishy.<br><br>Alex<br><br>Le 08/12/2023 à 13:24, Steven a écrit :<br><blockquote type="cite">Alexandre,<br><br><blockquote type="cite">Are you sure the DHCPv6-PD server is in Starlink network and not<br>on the<br>MikroTik router?<br></blockquote>That would be quite the unusual setup, and even so would require<br>that I obtain said /56 from elsewhere (such as via a tunnel) to<br>then delegate back to myself...<br><br><blockquote type="cite">It could be that the MikroTik router runs tunnelbroker, obtains a<br>/56<br>from HE, splits that /56 into multiple /64s and puts it on the<br>DHCPv6-PD<br>local server config files.<br></blockquote>I am confident this is not the case since I configured these<br>routers from scratch.<br><br><blockquote type="cite">It could also be that the DHCPv6-PD server is run on the Dishy.<br></blockquote>It is unlikely that it is on the Dishy, as the latency to the<br>DHCPv6 servers IP address, as well as the first IP hop, indicates<br>the usual Ground->Space->Ground latency I'd expect.<br><br><blockquote type="cite">It could also be that the DHCPv6-PD server is run on the starlink<br>ground<br>network: maybe on the teleport, maybe deeper on the starlink<br>network.<br></blockquote>Yes, this is the most likely place they are running this, likely<br>the PoP you are being routed through.<br><br><blockquote type="cite">Do you know the IPv6 address of your DHCPv6-PD Server?<br></blockquote>The DHCPv6 server address is a Starlink IPv6 address, the same one<br>as my default gateway (`2406:2d40:xxx:xxx::1`). The /56 I am being<br>allocated is also from the same /32 as this DHCPv6 server, with<br>the /32 being 2406:2d40::/32, which you'll note is allocated to<br>Starlink.<br><br>Cheers,<br>Steven<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote>_______________________________________________<br>Starlink mailing list<br>Starlink@lists.bufferbloat.net<br>https://lists.bufferbloat.net/listinfo/starlink</div></div></blockquote></div></blockquote></div><br></body></html>