Re: [Starlink] Info on IP country ranges

Sat, 06 Jan 2024 06:59:52 -0800 


Le 24/12/2023 à 02:29, Lukasz Bromirski via Starlink a écrit :



Maybe it's easier/better to "simply" use SSH over SCTP if keeping 
connection up while changing local gateway IP is requirement?



I think it is a good idea.  The ssh ability is probably the primary 
necessity in almost all computer-related works.  A stable ssh connection 
will help anything else make work.



SSH over SCTP (simultaneous), or even over simple TCP, will resist and 
come back up when the IP address changes, be that the IP address of 
intermediaries or of the host computer.  With SCTP, probably, will come 
back faster, and maybe offer higher bandwidth.


SSH over QUIC might work even better.

But there can be more to it than that.


There are other applications than ssh, which might not be able to take 
advantage of TCP's ability to restart, SCTP's simultaneous paths, or 
QUIC's other advantages.  Because they dont run on UDP or on other 
transport layers.



To make these non-ssh non-TCP/QUIC resist the changes of IP addresses 
they involve various mechanisms of restarting the app, buffering, and more.



One just has to make sure that the IP addresses of the ends, and the 
intermediary paths, stay up.  In in this respect starlink (as all ISPs) 
should strive to keep IP address stable for end users, and the IP paths up.


Alex



--
./


On 13 Dec 2023, at 23:57, Marc Blanchet via Starlink 
<starlink@lists.bufferbloat.net> wrote:





Le 13 déc. 2023 à 15:58, David Fernández via Starlink 
<starlink@lists.bufferbloat.net> a écrit :


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:

<quicssh.png>
moul/quicssh: SSH over QUIC <https://github.com/moul/quicssh>
github.com <https://github.com/moul/quicssh>

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


Marc.


Can you point to an explanation? Thank you!

Regards,

David



Date: Wed, 13 Dec 2023 09:37:40 -0500
From: Marc Blanchet <marc.blanc...@viagenie.ca>
To: Alexandre Petrescu <alexandre.petre...@gmail.com>
Cc: Sebastian Moeller <moell...@gmx.de>, Steven
<bufferbloat-li...@steven.honson.au>, starlink@lists.bufferbloat.net
Subject: Re: [Starlink] Info on IP country ranges
Message-ID: <1fe6b070-c2a0-4c35-8876-33feded81...@viagenie.ca>
Content-Type: text/plain;charset=utf-8




Le 13 déc. 2023 à 05:33, Alexandre Petrescu via Starlink
<starlink@lists.bufferbloat.net> a écrit :


Le 12/12/2023 à 11:50, Sebastian Moeller a écrit :

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


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 à 03:43, Steven a écrit :

Thanks for this reference that explicitly states it is IPv6 native.

https://support.starlink.com/?topic=1192f3ef-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.


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), p...@uvic.ca,
Web.UVic.CA/~pan

On Mon, Dec 11, 2023 at 5:10 PM 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 à 13:24, Steven a écrit :

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

_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink


_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net <mailto:Starlink@lists.bufferbloat.net>

https://lists.bufferbloat.net/listinfo/starlink 
<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























					Reply via email to