From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 8FB573CB40 for ; Thu, 14 Dec 2023 08:27:43 -0500 (EST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 3BEDRd2Y042416; Thu, 14 Dec 2023 14:27:39 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 103062051D8; Thu, 14 Dec 2023 14:27:39 +0100 (CET) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id F2DB4200C04; Thu, 14 Dec 2023 14:27:38 +0100 (CET) Received: from [10.8.32.70] (is156570.intra.cea.fr [10.8.32.70]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 3BEDRcAa059209; Thu, 14 Dec 2023 14:27:38 +0100 Message-ID: Date: Thu, 14 Dec 2023 14:27:38 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: fr To: David Lang Cc: Sebastian Moeller , Steven , starlink@lists.bufferbloat.net References: <361ee9d0d01da491a6e2b132317d170b@ausics.net> <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> <4rooss86-p114-8qp1-38r8-rn4302n99or4@ynat.uz> From: Alexandre Petrescu In-Reply-To: <4rooss86-p114-8qp1-38r8-rn4302n99or4@ynat.uz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CEA-Virus: SOPHOS_SAVI_ERROR_OLD_VIRUS_DATA 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: Thu, 14 Dec 2023 13:27:43 -0000 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