From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (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 B4E753B29E for ; Mon, 17 May 2021 22:22:05 -0400 (EDT) Received: by mail-ej1-x631.google.com with SMTP id l4so12060699ejc.10 for ; Mon, 17 May 2021 19:22:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=buraglio.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aY0Apjcx1I02yY+A6702iD5rwceXh9KZbILrpWdvdwg=; b=fHb22NYtonjtTrhrkx6AJh96LKNBAGkmS7vOx4DEtIZ4NOTygRvc66kxV2f0qcvyYA 2bLX2XU/tL4Nqj13bg7zaYmxD+pQHXUjPIjkoZ37ZF8wZplsOjFHvyJx+9tblntT0orR vzueHoPIWkp1BuNSFPZVcaM+tzGHbLb7ZpQQU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aY0Apjcx1I02yY+A6702iD5rwceXh9KZbILrpWdvdwg=; b=fB09PCtFktOZtPzArYHNEA89Idd6IVEPFXOKshUNYa57Bm3GtvPV5l59uh39d3iykm OG5DcGaipjwvCt38wCGBBJRP3kp9QDojEgiLfTL0knoQjvYBeno2VyWdTCxlYZkQeiFq nFQRQgmYJeNVRTZYgyWPzdfx2noFFm1TpcWUJaTCQfAtbvgGVE9995+h1DTLkxIont0l F8JNAeWvsdpAdlsUitqzQGxtVT0E1qV1A2Enw3qbd8eoSPPSnq94EWr+oMxmAjsU91aE urrxT5hOs5KMCeFrLCYQApm88DUoRMpY1vCa2HkQAKy1TcSi+GPdICKttiYw9OqzL2TQ YoSA== X-Gm-Message-State: AOAM533ZUWQtf4tsLFpIyTFrKF3SgejI3Rjk1tsRDdvIA6oSOx5eQQD7 fa6W0rE6GMwikCi1dNSWbj9JXcCcoyqvfDRoNIfzCw== X-Google-Smtp-Source: ABdhPJwk9tIVxQDqcKLI0CFqD0cdFxsRBA5175lcG3wea6+nOncovdpz5oaqSU7f+yanPLC3U/2bhlQZ/Z9R6DhNp0s= X-Received: by 2002:a17:906:1311:: with SMTP id w17mr3549156ejb.182.1621304524551; Mon, 17 May 2021 19:22:04 -0700 (PDT) MIME-Version: 1.0 References: <4FAEA212-C3A2-49E2-856C-33AEB864C75D@teklibre.net> In-Reply-To: <4FAEA212-C3A2-49E2-856C-33AEB864C75D@teklibre.net> From: Nick Buraglio Date: Mon, 17 May 2021 21:21:53 -0500 Message-ID: To: Dave Taht Cc: Dave Taht , Starlink@lists.bufferbloat.net Content-Type: multipart/alternative; boundary="000000000000424a5d05c2916086" Subject: Re: [Starlink] dhcpv6-pd details 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: Tue, 18 May 2021 02:22:05 -0000 --000000000000424a5d05c2916086 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Once we get a bit for there I=E2=80=99ll send it over. It=E2=80=99s not my = idea, I=E2=80=99m a contributor so I=E2=80=99ll need to ask first. On Mon, May 17, 2021 at 6:56 PM Dave Taht wrote: > > > On May 17, 2021, at 2:02 PM, Nick Buraglio wrote: > > The issue with this methodology (which I have used myself) is that it > relies on the host stack to do the heavy lifting. > > > Ah, we are talking about two slightly > different things. > > I was unhappy with relying on happy eyeballs for failover in the clients, > but withdrawing the address that were not working did not work well with > any clients we had at time. > > May I have a peek at your draft? > > Our draft handles most, if not all of this at the CPE, > > > It would be cool to implement something better at the cpe. > > which will allow for a significant amount of flexibility and reduction of > complexity at the host layer. That is a fairly large oversight in the > operational model for 90% of v6 users that aren't running BGP. One goal w= e > have is to reduce the time to connectivity failover and make deterministi= c > IPv6 paths easily implemented by non-technical folks, and to create a > standard for all CPE to implement with as minimal CPU as possible. > > nb > > On Mon, May 17, 2021 at 2:59 PM Dave Taht wrote: > >> On Mon, May 17, 2021 at 12:48 PM Nick Buraglio wrote= : >> > >> > I have this working now between my providers with straight routing and >> gateway checking, but it=E2=80=99s pretty easily doable other ways with = platforms >> like routerOS or pfsense. >> > FWIW, I=E2=80=99m working with some others on an IETF draft proposal t= hat will >> hopefully solve the plaguing problem of multiple IPv6 PD or otherwise >> provider assigned address blocks that will make a lot of that easier, to= o. >> >> Hmm? We solved this long ago in cerowrt, openwrt, and in linux, by >> using "source specific routing", which is the default for many openwrt >> derived OSes. >> >> Basically it looks like this: >> >> ip route add from 2001:abcd::/56 via whatever >> ip route add from 2001:dbcd::/56 via whatever2 >> >> You then distribute both sets of ipv6 addresses to the clients. Simple >> clean and it solved the bcp38 problem because there is no >> default route for any but these ipv6 addresses in the system. It works >> well for vpns also. >> >> Happy eyeballs takes care of the rest. >> >> https://datatracker.ietf.org/doc/html/draft-ietf-babel-source-specific-0= 8 >> describes how we added it to the babel routing protocol >> as well, so best hops can be easily chosen in a more complex network. >> In case I had 5+ comcast uplinks spread across a wifi campus so having >> multiple uplinks and failover was needed. It's been up and running >> for... 7 years? >> >> https://en.wikipedia.org/wiki/Source-specific_routing also made it >> into a few other places. >> >> I'm pretty certain every other OS completely missed this key feature >> of course including your mikrotik >> >> >> >> >> > >> > nb >> > >> > >> > On Mon, May 17, 2021 at 2:36 PM David Lang wrote: >> >> >> >> On Mon, 17 May 2021, Nick Buraglio wrote: >> >> >> >> > Inline >> >> > >> >> > On Mon, May 17, 2021 at 2:15 PM Dave Taht >> wrote: >> >> >> >> >> >> Starlink provides a router, also? I'm so confused. I thought the >> dishy >> >> >> was all there was. Care to tear it apart and describe what's in it= ? >> >> > >> >> > As far as the "router" is concerned, it's very much a consumer grad= e >> >> > device that is managed via the mobile app. I hated it, so I took it >> >> > out. It's still up in the attic. near the cable conduit, if I recal= l. >> >> >> >> Fantastic, I was hoping it would be something like this. I think this >> opens up a >> >> lot of more useful options (including more easily doing failover >> between the >> >> dish and other network options) >> >> >> >> David Lang >> >> >> >> -- >> Latest Podcast: >> https://www.linkedin.com/feed/update/urn:li:activity:6791014284936785920= / >> >> Dave T=C3=A4ht CTO, TekLibre, LLC >> > _______________________________________________ > > > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink > > > --000000000000424a5d05c2916086 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Once we get a bit for there I=E2=80=99ll send it over. It= =E2=80=99s not my idea, I=E2=80=99m a contributor so I=E2=80=99ll need to a= sk first.=C2=A0

On Mon, May 17, 2021 at 6:56 PM Dave Taht <davet@teklibre.net> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rg= b(204,204,204)">


On May 17, 2021, at 2:02 = PM, Nick Buraglio <nick@buraglio.com> wrote:

The issue= with this methodology (which I have used myself) is that it relies on the = host stack to do the heavy lifting.

Ah, we are talking about two slightly
different things.

I was unhappy with relying on happy eyeballs for failover = in the clients, but withdrawing the address that were not working did not w= ork well with any clients we had at time.

May I ha= ve a peek at your draft?

Our draft handles most, if not all of this at the CPE,

It would be cool to implement something bett= er at the cpe.

which will allo= w for a significant amount of flexibility and reduction of complexity at th= e host layer. That is a fairly large oversight in the operational model for= 90% of v6 users that aren't running BGP. One goal we have is to reduce= the time to connectivity failover and make deterministic IPv6 paths easily= implemented by non-technical=C2=A0folks, and to create a standard for all = CPE to implement with as minimal CPU as possible.=C2=A0

= nb=C2=A0

On Mon, May 17, 2021 at 2:59 PM Dave Taht <dave.taht@gmail.com> wro= te:
On Mon, May 17, 2021 at 12:48 PM Nick Buragli= o <nick@buraglio.= com> wrote:
>
> I have this working now between my providers with straight routing and= gateway checking, but it=E2=80=99s pretty easily doable other ways with pl= atforms like routerOS or pfsense.
> FWIW, I=E2=80=99m working with some others on an IETF draft proposal t= hat will hopefully solve the plaguing problem of multiple IPv6 PD or otherw= ise provider assigned address blocks that will make a lot of that easier, t= oo.

Hmm? We solved this long ago in=C2=A0 cerowrt, openwrt, and in linux, by using "source specific routing", which is the default for many op= enwrt
derived OSes.

Basically it looks like this:

ip route add from 2001:abcd::/56 via whatever
ip route add from 2001:dbcd::/56 via whatever2

You then distribute both sets of ipv6 addresses to the clients. Simple
clean and it solved the bcp38 problem because there is no
default route for any but these ipv6 addresses in the system. It works
well for vpns also.

Happy eyeballs takes care of the rest.

https://datatracker.ietf.or= g/doc/html/draft-ietf-babel-source-specific-08
describes how we added it to the babel routing protocol
as well, so best hops can be easily chosen in a more complex network.
In case I had 5+ comcast uplinks spread across a wifi campus so having
multiple uplinks and failover was needed. It's been up and running
for... 7 years?

https://en.wikipedia.org/wiki/Source-specific_r= outing also made it
into a few other places.

I'm pretty certain every other OS completely missed this key feature of course including your mikrotik




>
> nb
>
>
> On Mon, May 17, 2021 at 2:36 PM David Lang <david@lang.hm> wrote:
>>
>> On Mon, 17 May 2021, Nick Buraglio wrote:
>>
>> > Inline
>> >
>> > On Mon, May 17, 2021 at 2:15 PM Dave Taht <dave.taht@gmail.com> wrote= :
>> >>
>> >> Starlink provides a router, also? I'm so confused. I = thought the dishy
>> >> was all there was. Care to tear it apart and describe wha= t's in it?
>> >
>> > As far as the "router" is concerned, it's very = much a consumer grade
>> > device that is managed via the mobile app. I hated it, so I t= ook it
>> > out. It's still up in the attic. near the cable conduit, = if I recall.
>>
>> Fantastic, I was hoping it would be something like this. I think t= his opens up a
>> lot of more useful options (including more easily doing failover b= etween the
>> dish and other network options)
>>
>> David=C2=A0 Lang



--
Latest Podcast:
https://www.linkedin.com/fe= ed/update/urn:li:activity:6791014284936785920/

Dave T=C3=A4ht CTO, TekLibre, LLC
_______________________________________________
--000000000000424a5d05c2916086--