<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>For all I can tell, dishy only uses one satellite at a time and
so routing via dishys to other satellites - while certainly an
attractive concept - doesn't seem to be happening.</p>
<p>Most modern comms systems - look at your phone - run pretty
complicated stacks these days, and I'd be very surprised if
Starlink didn't. That makes it likely that there is an extra
network and transport layer between dishy and gateway (a term,
which I'm incidentally not using for the WiFi router that comes
with dishy but for the gateways that connect the Starlink space
network to the terrestrial Internet). Any routing between dishy,
satellite and gateway (and any lasers along the way) will
therefore be happening at that extra network layer - the transport
layer above it has the job to make the path between dishy and
gateway look like a single data link layer hop. This is why you
don't see a satellite IP in your traceroute. Quite how that extra
network and transport layer is implemented is something that
probably only Starlink knows. The power of layered communication
;-)</p>
<p>P.S.: I'll apologise in advance for upcoming silence over the
next few days - we're taking Dishy for an outing to get it away
from the Clevedon gateway, so we can finally get Dave some more
data ;-)<br>
</p>
<div class="moz-cite-prefix">On 18/04/2023 7:09 am, David Lang via
Starlink wrote:<br>
</div>
<blockquote type="cite" cite="mid:1n21p043-oqps-r637-p502-p51op49pqoss@ynat.uz">
if Starlink can route via in-space-lasers and in a dishy-to-dishy
way (both have <br>
been talked about, at least in future tenses) then they could also
route to an <br>
on-satellite IP.<br>
<br>
historically 'bent pipe' satellite support meant that the
satellite just <br>
repeated the RF signal back down with no modifications. Starlink
was designed to <br>
do routing of traffic, some to a ground station (possibly more
than one), some <br>
to other satellites (including ones at different altitudes), and
some to other <br>
dishys. It's initial deployment included no routing, just relaying
between a <br>
dishy and a ground station, but we know that it's extended beyond
that, at least <br>
when there are not ground stations in range<br>
<br>
David Lang<br>
<br>
On Mon, 17 Apr 2023, David Fernández via Starlink wrote:<br>
<br>
> Well, I have some concerns about how you implement an anycast
address<br>
> in a transparent satellite.<br>
><br>
> If the pre-requisite for this is that the satellite is a
router, I<br>
> don't see this happening anytime soon. I am not aware of any
system,<br>
> not deployed, even designed with satellites being routers,
but IRIS2<br>
> could be the first, maybe:<br>
> <a href="https://defence-industry-space.ec.europa.eu/eu-space-policy/eu-space-programme/iriss_en" moz-do-not-send="true">https://defence-industry-space.ec.europa.eu/eu-space-policy/eu-space-programme/iriss_en</a><br>
><br>
> Bufferbloat will be checked and prevented as much as possible
in IRIS2.<br>
><br>
> Regards,<br>
><br>
> David<br>
><br>
> 2023-04-17 16:38 GMT+02:00, Rodney W. Grimes
<a class="moz-txt-link-rfc2396E" href="mailto:starlink@gndrsh.dnsmgr.net"><starlink@gndrsh.dnsmgr.net></a>:<br>
>>> On Sun, 16 Apr 2023, David Fern?ndez via Starlink
wrote:<br>
>>><br>
>>> > The idea would be that the satellite inspects IP
packets and when it<br>
>>> > detects a DNS query, instead of forwarding the
packet to ground<br>
>>> > station, it just answers back to the sender of
the query.<br>
>>><br>
>>> This would be a bad way to implement it. You don't
want to override<br>
>>> queries to<br>
>>> other DNS servers, but it would be very easy to
create an anycast address<br>
>>> that<br>
>>> is served by the satellites.<br>
>><br>
>> Yes, and the later is what I proposed, the idea of
intercepting<br>
>> someone ELSE'S anycast address and processing it would be<br>
>> wrong in many ways, in effect a Man In the Middle attack<br>
>> as stated else where.<br>
>><br>
>>> David Lang<br>
>> --<br>
>> Rod Grimes<br>
>> <a class="moz-txt-link-abbreviated" href="mailto:rgrimes@freebsd.org">rgrimes@freebsd.org</a><br>
>><br>
> _______________________________________________<br>
> Starlink mailing list<br>
> <a class="moz-txt-link-abbreviated" href="mailto:Starlink@lists.bufferbloat.net">Starlink@lists.bufferbloat.net</a><br>
> <a href="https://lists.bufferbloat.net/listinfo/starlink" moz-do-not-send="true">https://lists.bufferbloat.net/listinfo/starlink</a>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Starlink mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Starlink@lists.bufferbloat.net">Starlink@lists.bufferbloat.net</a>
<a class="moz-txt-link-freetext" href="https://lists.bufferbloat.net/listinfo/starlink">https://lists.bufferbloat.net/listinfo/starlink</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
****************************************************************
Dr. Ulrich Speidel
School of Computer Science
Room 303S.594 (City Campus)
The University of Auckland
<a class="moz-txt-link-abbreviated" href="mailto:u.speidel@auckland.ac.nz">u.speidel@auckland.ac.nz</a>
<a class="moz-txt-link-freetext" href="http://www.cs.auckland.ac.nz/~ulrich/">http://www.cs.auckland.ac.nz/~ulrich/</a>
****************************************************************
</pre>
</body>
</html>