From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.taht.net (mail.taht.net [IPv6:2a01:7e00:e000:2d4:f00f:f00f:b33b:b33b]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 5F8E63B29E for ; Mon, 17 May 2021 19:56:26 -0400 (EDT) Received: from smtpclient.apple (c-73-241-93-6.hsd1.ca.comcast.net [73.241.93.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id ADCD222C86; Mon, 17 May 2021 23:56:24 +0000 (UTC) From: Dave Taht Message-Id: <4FAEA212-C3A2-49E2-856C-33AEB864C75D@teklibre.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_A45037A3-235C-44E7-8BB4-7DB0143FA42D" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Date: Mon, 17 May 2021 16:56:22 -0700 In-Reply-To: Cc: Dave Taht , Starlink@lists.bufferbloat.net To: Nick Buraglio References: X-Mailer: Apple Mail (2.3654.80.0.2.43) 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: Mon, 17 May 2021 23:56:27 -0000 --Apple-Mail=_A45037A3-235C-44E7-8BB4-7DB0143FA42D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 17, 2021, at 2:02 PM, Nick Buraglio wrote: >=20 > 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 = we have is to reduce the time to connectivity failover and make = deterministic IPv6 paths easily implemented by non-technical folks, and = to create a standard for all CPE to implement with as minimal CPU as = possible.=20 >=20 > nb=20 >=20 > 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 = that will hopefully solve the plaguing problem of multiple IPv6 PD or = otherwise provider assigned address blocks that will make a lot of that = easier, too. >=20 > 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. >=20 > Basically it looks like this: >=20 > ip route add from 2001:abcd::/56 via whatever > ip route add from 2001:dbcd::/56 via whatever2 >=20 > 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. >=20 > Happy eyeballs takes care of the rest. >=20 > = https://datatracker.ietf.org/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? >=20 > https://en.wikipedia.org/wiki/Source-specific_routing = also made it > into a few other places. >=20 > I'm pretty certain every other OS completely missed this key feature > of course including your mikrotik >=20 >=20 >=20 >=20 > > > > 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 = grade > >> > 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 = recall. > >> > >> 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 >=20 >=20 >=20 > --=20 > Latest Podcast: > = https://www.linkedin.com/feed/update/urn:li:activity:6791014284936785920/ = >=20 > Dave T=C3=A4ht CTO, TekLibre, LLC > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink --Apple-Mail=_A45037A3-235C-44E7-8BB4-7DB0143FA42D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

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 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 we have is to reduce the time to = connectivity failover and make deterministic 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 <dave.taht@gmail.com>= wrote:
On Mon, May 17, 2021 at 12:48 PM Nick = Buraglio <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 platforms like routerOS or pfsense.
> FWIW, I=E2=80=99m working with some others on an IETF draft = proposal that will hopefully solve the plaguing problem of multiple IPv6 = PD or otherwise provider assigned address blocks that will make a lot of = that easier, too.

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-s= pecific-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_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 <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 = what'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 took 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 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:6791014284= 936785920/

Dave T=C3=A4ht CTO, TekLibre, LLC
_______________________________________________
Starlink = mailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink

= --Apple-Mail=_A45037A3-235C-44E7-8BB4-7DB0143FA42D--