Le 13/12/2023 à 19:27, David Lang a écrit :
On Wed, 13 Dec 2023, Alexandre Petrescu via Starlink wrote:
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.
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).
There are two types of keeping your address. One is to have the same
address all the time, the other is to keep your address during a session.
Fair enough.
Even if you get a public address, it can change from time to time
(just like DHCP addresses could on landline ISPs),
Well, it depends on ISP. Indeed some wireline ISPs change the address
of home customers relatively often - on DHCP lease expiry, MAC-less or
NAI-less DHCP during reboots, etc. But other landline ISPs do provide
always the same IP address to customers. Some times it is even part of
the signed contract.
but that doesn't mean that your address will change during a session
(i.e. while you are powered up and connected) even while moving around.
Do you mean that the /56 I'd get from starlink with DHCPv6-PD would stay
the same if I had ongoing sessions, and moved in and out the hexagon
cells,or even in-out of a teleport coverage? (driving a car on a longer
distance).
Remark that /56 can not be equated simply to the behaviour of an IPv4
address. That /56 means more than just one address and, additionally,
it is bound to an IPv6 address to which it is routed (either a GUA or a
LL, a 'next-hop' address).
The maintenance of that /56 constant can happen with or without
maintenance of the 'next-hop' address constant.
If starlink keeps constant both the 'next-hop' address and the allocated
/56 during movements to very wide distances (cell-to-cell,
teleport-to-teleport) then it could some options.
If starlink keeps constant just the /56 allocated to end user, and
varies the 'next-hop' address attached to it then it would other options.
There are design options.
If you get a public IP, that IP will change like a DHCP address would
on a landline ISP, rarely and mostly when equipment at one end or
another was restarted, but not every time you do a new satellite handoff
satellite handoff: do you mean the handoff provoked by the movement of
satellites to a ground-fixed user, or do you mean the movement of end
user in and out of hexagon cells covered by satellites?
IMHO, I think it can mean either of the two. For the latter (movement
of end user between cells) there'd probably be another /56 delegated to
an end user, regardless of having ongoing sessions - DHCP does not check
the status of apps.
Further, a very wide area movement might provoke a change in teleport,
not just a change in hexagon cells. A change in teleport certainly
provokes a change in the allocated /56 of the end user, again regardless
of her having running sessions. In order to keep a same /56 allocated
to a same end user handed over from one teleport to another there would
be a need of some teleport-to-teleport protocol, maybe a tunnelled BGP,
or other.
Alex
David Lang
_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink
