From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw1-x1129.google.com (mail-yw1-x1129.google.com [IPv6:2607:f8b0:4864:20::1129]) (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 63BF63CB39 for ; Fri, 8 Dec 2023 00:57:17 -0500 (EST) Received: by mail-yw1-x1129.google.com with SMTP id 00721157ae682-5d8ddcc433fso14377827b3.1 for ; Thu, 07 Dec 2023 21:57:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1702015036; x=1702619836; darn=lists.bufferbloat.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ievOB4t6x7LVuf8yeof5mEKC+bGGvPl1YiLRSKNwTRY=; b=PXVtj0hREEsejFNwgIZKm3d4GsJQWGr8IF+VY+GMTqLy+l4b4rHgePHVCoUlq6U+J7 SLGpXfDOfuHDJo4YTpN3PTmJebeIyNPXMFwacBTQr+tKa6h+eQfKTODZ+ZZr17k802/r xl85f3KCEa706/ntRSjdq1z2z2RyNTRp5XfZkQpXhIPS/CaBgHpxfK7fA/lhxlIhZZGd etPon+ZUpM674v/6Mt/42fP5IPBrgiiU63LM8J1yxz9nYW1M2SYMizi5WM5b2+m19s9V h89i3p+r+4sWrkWzRn3C9EaP51wOh5519YGjkgz5jm4a1qOnCB46usTr6El6kKTyK+vq imWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702015036; x=1702619836; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ievOB4t6x7LVuf8yeof5mEKC+bGGvPl1YiLRSKNwTRY=; b=LuaRh2td+5sAezMlbKBkdG9NZO9B/Wda3jJpsw84kc2/fWaZYXec0v2j5p3ZrwztCj XSPh0jbDEUc7p4JxP7ASQa5lDBk/N4rZS3Z03dY4TEGc1vHRsU0d7CuzVS9WkeZEZftr paRfQykKNJuSYO6/zNygf9loMx5IXhv8+TyIyHUEBCYAqheGdxvCbxKWyFrJgqwCqTZb Z2swRUP9FaGcF3q52A1TEf7nmHiChfhwa+yFSDnfrMDo4xy4RWtHIK2xUKT7jf6u9j+U IFNBscmae2wvYLUiHMXXxau84SJdOD8nS2lGD8GkMsFtPQ3kibfvpfWA/TlC0TolTli1 ABjw== X-Gm-Message-State: AOJu0YyXqHys7hshHg/iUi0NUNxEiiX46zgPGgOZ0v+i6YaPNkvKd/UC EOaG1yF9atfA2UFGkdkQlO+Kdpikk1FC+hPifc0= X-Google-Smtp-Source: AGHT+IHNbORFhnlmwpYOkjiQCz1APgiBP0YYm6EASDR/bp152fItedeeX5khJK787nYu+1kXUkGdwaXjj7rdJ35X7do= X-Received: by 2002:a25:ab27:0:b0:db7:dacf:4d87 with SMTP id u36-20020a25ab27000000b00db7dacf4d87mr2734338ybi.131.1702015036472; Thu, 07 Dec 2023 21:57:16 -0800 (PST) MIME-Version: 1.0 References: <361ee9d0d01da491a6e2b132317d170b@ausics.net> <75790520d6c8d35beb7248f5f5dff952@ausics.net> <924492fc-6ce4-4e62-82d9-c8f0b50ee96d@gmail.com> In-Reply-To: <924492fc-6ce4-4e62-82d9-c8f0b50ee96d@gmail.com> From: Freddie Cash Date: Thu, 7 Dec 2023 21:57:04 -0800 Message-ID: To: Alexandre Petrescu Cc: starlink@lists.bufferbloat.net Content-Type: multipart/alternative; boundary="000000000000a6c10f060bf94120" 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: Fri, 08 Dec 2023 05:57:17 -0000 --000000000000a6c10f060bf94120 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dishy gets a /64 and I've tested DHCPv6 on both my Firewalla and my USG. They do prefix delegation to distribute that as a /56 locally. No NAT required for IPv6 (incoming or outgoing) connections. And there doesn't appear to be any restrictions on IPv6 traffic. This is with the round Dishy. Cheers, Freddie Typos due to smartphone keyboard. On Thu, Dec 7, 2023, 3:54 a.m. Alexandre Petrescu via Starlink < starlink@lists.bufferbloat.net> wrote: > > Le 04/12/2023 =C3=A0 19:17, J Pan via Starlink a =C3=A9crit : > > yes, starlink does respond to its customers' complaints, although > > sometimes slowly. its ipv4 address acquisition is scattered around as > > a latecomer to the isp world, and as a global local isp, it's more > > troublesome. ip packets have to be tunneled back to its home pop where > > nat and other functions happen, sometimes around the world, causing a > > much higher minimum rtt fluctuation in 15-second handover > > intervals---bad for network protocols and applications. ipv6 can do > > better but currently follows the same route as ipv4---an incentive to > > promote ipv6 ;-) > > Excellent incentive! > > It would be good to know whether the dishy router obtains a /56 or a /64 > prefix from the starlink ISP. That is easy to find out by just looking > at the packets. This would tell whether a NAT can be avoided at home, > and hence more apps made possible. > > IT would also be good to know whether the claimed IPv6 access on dishy > is via a tunnel (IPv6 in IPv6, or IPv6 in IPv4) or it is 'native' (no > tunnel). That will tell many things about additional latency that might > be brought in by IPv6. (we'd want less latency, not more). > > After that, one can look more at promoting IPv6. Otherwise, IPv6 might > still look as a hurdle, an obstacle, additional work that is too little > necessary, or might even be worse than IPv4. > > Alex > > > -- > > J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, > Web.UVic.CA/~pan > > > > On Mon, Dec 4, 2023 at 4:04=E2=80=AFAM Noel Butler > wrote: > >> Thanks, it seems they are trying it on then :) > >> > >> On 04/12/2023 10:44, J Pan wrote: > >> > >> starlink advertises its customer ip address location at > >> http://geoip.starlinkisp.net (not always updated but good enough in > >> most cases and traceroute can confirm to some extent as well) > >> -- > >> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, > Web.UVic.CA/~pan > >> > >> On Sun, Dec 3, 2023 at 4:15=E2=80=AFPM Noel Butler via Starlink > >> wrote: > >> > >> > >> I run an open access usenet server, but only for those within my CC, s= o > access is by IP based on our CC allocations from APNIC. > >> > >> Because IPv4 exhaustion this changes sometimes with buying allocations > from other regions, and if they get denied access I encourage them to let > us know so we can keep ACL's updated, I've had a request from a starlink > user who claims they are here, but traceroute shows them in .DE > >> > >> tracing some 217.foo.ad.dr > >> > >> ... > >> 9 ae-6.r21.frnkge13.de.bb.gin.ntt.net (129.250.3.183) 290.223 ms > 290.180 ms ae-1.r20.frnkge13.de.bb.gin.ntt.net (129.250.7.35) 280.523 ms > >> 10 ae-1.a03.frnkge13.de.bb.gin.ntt.net (129.250.3.152) 290.109 ms > 289.667 ms 292.864 ms > >> 11 ae-0.spacex.frnkge13.de.bb.gin.ntt.net (213.198.72.19) 279.611 ms > 278.840 ms 279.592 ms > >> 12 undefined.hostname.localhost (206.224.65.189) 280.127 ms 278.506 ms > 284.265 ms > >> 13 undefined.hostname.localhost (206.224.65.209) 284.198 ms > undefined.hostname.localhost (206.224.65.201) 274.663 ms 273.073 ms > >> 14 * * * > >> > >> > >> As it is our policy to not collect any user info or issue user/pass's > and only allow access by IP, I'm hoping someone here knows if they are > full of it, or does starlink really assign addresses from anywhere? That > one hardly makes sense for user experience, or maybe starlink has so few > users in this country they haven't bothered changing anything yet? > >> > >> -- > >> > >> Regards, > >> Noel Butler > >> > >> > >> _______________________________________________ > >> Starlink mailing list > >> Starlink@lists.bufferbloat.net > >> https://lists.bufferbloat.net/listinfo/starlink > >> > >> > >> -- > >> > >> Regards, > >> Noel Butler > >> > >> > > _______________________________________________ > > 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 > --000000000000a6c10f060bf94120 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dishy gets a /64 and I've tested DHCPv6 on both my Fi= rewalla and my USG. They do prefix delegation to distribute that as a /56 l= ocally.

No NAT required for IP= v6 (incoming or outgoing) connections. And there doesn't appear to be a= ny restrictions on IPv6 traffic.

This is with the round Dishy.

Cheers,
Freddie

Typos due to smartphone = keyboard.

On Thu, Dec 7, 2023, 3:54 a.m. Alexandre Petrescu via = Starlink <starlink@lis= ts.bufferbloat.net> wrote:
<= br> Le 04/12/2023 =C3=A0 19:17, J Pan via Starlink a =C3=A9crit=C2=A0:
> yes, starlink does respond to its customers' complaints, although<= br> > sometimes slowly. its ipv4 address acquisition is scattered around as<= br> > a latecomer to the isp world, and as a global local isp, it's more=
> troublesome. ip packets have to be tunneled back to its home pop where=
> nat and other functions happen, sometimes around the world, causing a<= br> > much higher minimum rtt fluctuation in 15-second handover
> intervals---bad for network protocols and applications. ipv6 can do > better but currently follows the same route as ipv4---an incentive to<= br> > promote ipv6 ;-)

Excellent incentive!

It would be good to know whether the dishy router obtains a /56 or a /64 prefix from the starlink ISP.=C2=A0 That is easy to find out by just lookin= g
at the packets.=C2=A0 This would tell whether a NAT can be avoided at home,=
and hence more apps made possible.

IT would also be good to=C2=A0 know whether the claimed IPv6 access on dish= y
is via a tunnel (IPv6 in IPv6, or IPv6 in IPv4) or it is 'native' (= no
tunnel).=C2=A0 That will tell many things about additional latency that mig= ht
be brought in by IPv6.=C2=A0 (we'd want less latency, not more).

After that, one can look more at promoting IPv6.=C2=A0 Otherwise, IPv6 migh= t
still look as a hurdle, an obstacle, additional work that is too little necessary, or might even be worse than IPv4.

Alex

> --
> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, W= eb.UVic.CA/~pan
>
> On Mon, Dec 4, 2023 at 4:04=E2=80=AFAM Noel Butler <noel.butler= @ausics.net> wrote:
>> Thanks, it seems they are trying it on then :)
>>
>> On 04/12/2023 10:44, J Pan wrote:
>>
>> starlink advertises its customer ip address location at
>> http://geoip.starlinkisp.net (not always updated= but good enough in
>> most cases and traceroute can confirm to some extent as well)
>> --
>> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan
>>
>> On Sun, Dec 3, 2023 at 4:15=E2=80=AFPM Noel Butler via Starlink >> <starlink@lists.bufferbloat.net> wrote:
>>
>>
>> I run an open access usenet server, but only for those within my C= C, so access is by IP based on our CC allocations from APNIC.
>>
>> Because IPv4 exhaustion this changes sometimes with buying allocat= ions from other regions, and if they get denied access I encourage them to = let us know so we can keep ACL's updated, I've had a request from a= starlink user who claims they are here, but traceroute shows them in .DE >>
>> tracing some 217.foo.ad.dr
>>
>> ...
>> 9 ae-6.r21.frnkge13.de.bb.gin.ntt.net<= /a> (129.250.3.183) 290.223 ms 290.180 ms ae-1.= r20.frnkge13.de.bb.gin.ntt.net (129.250.7.35) 280.523 ms
>> 10 ae-1.a03.frnkge13.de.bb.gin.ntt.net= (129.250.3.152) 290.109 ms 289.667 ms 292.864 ms
>> 11 ae-0.spacex.frnkge13.de.bb.gin= .ntt.net (213.198.72.19) 279.611 ms 278.840 ms 279.592 ms
>> 12 undefined.hostname.localhost (206.224.65.189) 280.127 ms 278.50= 6 ms 284.265 ms
>> 13 undefined.hostname.localhost (206.224.65.209) 284.198 ms undefi= ned.hostname.localhost (206.224.65.201) 274.663 ms 273.073 ms
>> 14 * * *
>>
>>
>> As it is our policy to not collect any user info or issue user/pas= s's and=C2=A0 only allow access by IP, I'm hoping someone here know= s if they are full of it, or does starlink really assign addresses from any= where? That one hardly makes sense for user experience, or maybe starlink h= as so few users in this country they haven't bothered changing anything= yet?
>>
>> --
>>
>> Regards,
>> Noel Butler
>>
>>
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/lis= tinfo/starlink
>>
>>
>> --
>>
>> Regards,
>> Noel Butler
>>
>>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinf= o/starlink
_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/sta= rlink
--000000000000a6c10f060bf94120--