From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (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 541513CB37 for ; Wed, 13 Dec 2023 17:59:15 -0500 (EST) Received: by mail-vs1-xe2c.google.com with SMTP id ada2fe7eead31-464754e1120so2256111137.1 for ; Wed, 13 Dec 2023 14:59:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=viagenie-ca.20230601.gappssmtp.com; s=20230601; t=1702508354; x=1703113154; darn=lists.bufferbloat.net; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=p7hnOG69QZFP/ILZCGc4Qy9yQeh7UznfPHUk25atJY0=; b=cNyZ+y6oDkMD89MbAsuHmw9z3COILq21ha883GwFX1WtMnu/uObkbLv9xk00u3s7me wnOEXr6oBhDKqES+wD3C/N1Fh/G2jfi7rKl6P5p8srvuYMkOV1omB6IHrOS/zFsv8LpU NFbzEGwMzIYmHwGjldBqBtD0al0Zf9GblQiWbHFCwKgzTlQek9pQ9rZPYaEGs5wCuBxv nLAOLKvpIB1nnRW22spFih/Dnq415sxo/56TGhB/WdRiIKuXxxv84sDK5SSar+UgEyza jDIFXSF+SejBK5+tE+vgDQeUVli5nlaROSaaak7XfxjFaxjSr8bJyonx1Dq5MaZltEBv zv9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702508354; x=1703113154; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=p7hnOG69QZFP/ILZCGc4Qy9yQeh7UznfPHUk25atJY0=; b=OL/MjFyePbwKkj3PIMIWBLq2cltDJ9cuBb5iYimIQRGdzwV1eynj+QJkZuhiFiVv8S SwpXNTHTh/egQZ/OgUOqDw4TXvr8ddJXBL/7+eonzrhiB2AZyvO/O3ft4sWjpLiZXMbp Kf3Tqb/ryF+PvdeGf1opmLjvu0uTjB//hw/Rd/4ZY3WK+68Mi24rDsKl8uDzIi7fxbSD Ojm5jBEjFjERyRnWk8+H40eiAR7jxGMCS+eEkOjH3S3qSvAVaqp1xxv2vT7VXfW8S+Vf kP1t+oyspucHA4wrqScFA0nBdQo9dK2syIDi+d271Iq2ucKcFJlzpMZFpPAUUc1/1KOV ea/Q== X-Gm-Message-State: AOJu0Yx9r+V6TXAyE1oAYkmDZG4aci3Ar45qQVuHtjln1s7Vdhs791Eu 1mJpBWGouciWam05v3YJQmhwIg== X-Google-Smtp-Source: AGHT+IFO9gVNisUVxVVOL9ukNWPo+rJet8GSL4VT0v2gkqZeKkRUgwIujaQ2HW/DxeGpx0SlK6vY/Q== X-Received: by 2002:a05:6102:370b:b0:465:d461:e9c1 with SMTP id s11-20020a056102370b00b00465d461e9c1mr6765422vst.69.1702508354358; Wed, 13 Dec 2023 14:59:14 -0800 (PST) Received: from smtpclient.apple (modemcable161.124-162-184.mc.videotron.ca. [184.162.124.161]) by smtp.gmail.com with ESMTPSA id z7-20020a0cd787000000b0067ee768638asm1805505qvi.7.2023.12.13.14.59.13 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Dec 2023 14:59:13 -0800 (PST) From: Marc Blanchet Message-Id: <79AADC32-6FC4-4277-9F70-D0886F3B32A4@viagenie.ca> Content-Type: multipart/alternative; boundary="Apple-Mail=_2259A734-262E-4C2B-8CBD-9DCFEA572B2D" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Date: Wed, 13 Dec 2023 17:59:02 -0500 In-Reply-To: <797EE470-B7D6-4A28-81D5-7A283712AB08@viagenie.ca> Cc: starlink@lists.bufferbloat.net To: =?utf-8?Q?David_Fern=C3=A1ndez?= References: <797EE470-B7D6-4A28-81D5-7A283712AB08@viagenie.ca> X-Mailer: Apple Mail (2.3774.300.61.1.2) 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 22:59:15 -0000 --Apple-Mail=_2259A734-262E-4C2B-8CBD-9DCFEA572B2D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Le 13 d=C3=A9c. 2023 =C3=A0 17:57, Marc Blanchet = a =C3=A9crit : >=20 >=20 >=20 >> Le 13 d=C3=A9c. 2023 =C3=A0 15:58, David Fern=C3=A1ndez via Starlink = a =C3=A9crit : >>=20 >> Hi, >>=20 >> 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." >>=20 >> What is that way? >=20 > 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: > https://github.com/moul/quicssh > 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. I should add that someone wrote a draft on SSH over QUIC natively = (draft-bider-ssh-quic) but seems dead and no implementation known=20 Marc. >=20 > Marc. >=20 >> Can you point to an explanation? Thank you! >>=20 >> Regards, >>=20 >> David >>=20 >>=20 >>> 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 >>>=20 >>>=20 >>>=20 >>>> 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. >>>=20 >>> I would be very (happily) surprised if they do support that. >>>=20 >>>>=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). >>>=20 >>> 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 >>>=20 >>>>=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 --Apple-Mail=_2259A734-262E-4C2B-8CBD-9DCFEA572B2D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Le 13 d=C3=A9c. 2023 =C3=A0 17:57, Marc Blanchet = <marc.blanchet@viagenie.ca> a =C3=A9crit :



Le 13 d=C3=A9c. 2023 =C3=A0 15:58, David = Fern=C3=A1ndez via Starlink <starlink@lists.bufferbloat.net> 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:
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.

I should add that = someone wrote a draft on SSH over QUIC natively (draft-bider-ssh-quic) = but seems dead and no implementation = known 

Marc.


Marc.

Can you point to an explanation? Thank = you!

Regards,

David


Date: Wed, 13 Dec 2023 09:37:40 -0500
From: Marc = Blanchet <marc.blanchet@viagenie.ca>
To: Alexandre Petrescu = <alexandre.petrescu@gmail.com>
Cc: Sebastian Moeller = <moeller0@gmx.de>, Steven
= <bufferbloat-lists@steven.honson.au>, = 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
<starlink@lists.bufferbloat.net> 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
<starlink@lists.bufferbloat.net> 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 visible
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 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?

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 to
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 going
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 = native.

https://support.starlink.com/?topic=3D1192f3ef-2a17-31d9-26= 1a-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.

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 = 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.

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.

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-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
<starlink@lists.bufferbloat.net> 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 advantageous to
use
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
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 can 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 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.

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 these
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 the
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 = starlink
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 allocated = to
Starlink.

Cheers,
Steven
=
_______________________________________________<= br>Starlink mailing = list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/li= stinfo/starlink

= --Apple-Mail=_2259A734-262E-4C2B-8CBD-9DCFEA572B2D--