[LibreQoS] how are you doing on ipv4 address supply?

[LibreQoS] how are you doing on ipv4 address supply?

[Dave Taht]

in my continued rip-van-winkle, living in the third world (california)
way, I am curious as to how y'all are managing your
ipv4 address supply and if you are deploying ipv6 to any extent?

In all this discussion of multi-gbit fiber, my own direct experience
is that AT&T's fiber rollout had very flaky ipv6, and more and more
services (like starlink) are appearing behind cgnats, which have their
own capex and opex costs.

I see a lot of rfc1918 being used as the operational overlay
elsewhere, tons of tunnels, also.

-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz
Dave Täht CEO, TekLibre, LLC

Re: [LibreQoS] how are you doing on ipv4 address supply?

[dan]

[-- Attachment #1: Type: text/plain, Size: 1966 bytes --]

we use RFC6598 addressing and CGNAT on the edge unless someone pays for an
IP.  Very slowly getting IPv6 implementation down.  Poor CRM/Shaper support
for it being a big struggle.  Preseem+UISP for example requires that
whatever is handling IPv6 PD be pollable from preseem so they can grab
MAC:PD prefix and combine them.  VISP has implemented this better recently
but I haven't fully implemented yet, that's a goal for this month.

We don't 'tunnel' ie no MPLS/VPLS, SRV6, EVPN right now.  We technically do
GRE tunneling, terragraph works just like OSPFv3 on IPv6 w/ GRE tunnels.

Part of the reason not to tunnel is that we don't have a single headend, we
have regional POPs and interconnections between so we can reduce outages
caused by the POPs.  Fully routed seems to only non-convoluted way to
handle this.  Not interested in a VRRP moving my tunnel endpoint addresses
between regions, that's a mess.  And so we route.

On Tue, Oct 25, 2022 at 9:30 PM Dave Taht via LibreQoS <
libreqos@lists.bufferbloat.net> wrote:

> in my continued rip-van-winkle, living in the third world (california)
> way, I am curious as to how y'all are managing your
> ipv4 address supply and if you are deploying ipv6 to any extent?
>
> In all this discussion of multi-gbit fiber, my own direct experience
> is that AT&T's fiber rollout had very flaky ipv6, and more and more
> services (like starlink) are appearing behind cgnats, which have their
> own capex and opex costs.
>
> I see a lot of rfc1918 being used as the operational overlay
> elsewhere, tons of tunnels, also.
>
> --
> This song goes out to all the folk that thought Stadia would work:
>
> https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz
> Dave Täht CEO, TekLibre, LLC
> _______________________________________________
> LibreQoS mailing list
> LibreQoS@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/libreqos
>

[-- Attachment #2: Type: text/html, Size: 2637 bytes --]

Re: [LibreQoS] how are you doing on ipv4 address supply?

[Herbert Wolverson]

[-- Attachment #1: Type: text/plain, Size: 2455 bytes --]

Actually had a conversation with our primary upstream provider yesterday
about IPv6 (and why
they won't provide it to us). One of their lead engineers, once plied with
beer, said that every
time they've deployed it they get 99% of it working well and 1% of things
mysteriously
stop working, or go wonky. That was similar to our experience a few years
ago. It mostly
helped a lot, but chasing down the "hey, this advertises a v6 address and
doesn't actually
support it" issues drove us crazy.

Right now, we don't have enough IPv4 addresses, but that's being rectified.
We mostly
do CGNAT and 10.64 addresses in the meantime, with public IPs assigned
where they
are needed (mostly through a tunnel setup to avoid subnetting waste).
Tunnels are a pain,
but they work (once you chase down all of the MTU issues).

Which reminds me, I have "can we support MPLS?" on my crazy notes list. I
know that
Preseem and similar don't try, but we're already reading deeply enough into
the ethernet
header that saying "this is an MPLS label, advance 4 bytes", "this is a
VPLS label, advance
X (I forget) bytes" looks do-able. [Note, I personally don't enjoy MPLS.
It's handy when
you want to pretend to have a flat network on top of a large routed network
- and some
WISP consultants absolutely swear by it - but my experience is that you are
adding
complexity for the sake of it. Routing works remarkably well.]

On Tue, Oct 25, 2022 at 10:30 PM Dave Taht via LibreQoS <
libreqos@lists.bufferbloat.net> wrote:

> in my continued rip-van-winkle, living in the third world (california)
> way, I am curious as to how y'all are managing your
> ipv4 address supply and if you are deploying ipv6 to any extent?
>
> In all this discussion of multi-gbit fiber, my own direct experience
> is that AT&T's fiber rollout had very flaky ipv6, and more and more
> services (like starlink) are appearing behind cgnats, which have their
> own capex and opex costs.
>
> I see a lot of rfc1918 being used as the operational overlay
> elsewhere, tons of tunnels, also.
>
> --
> This song goes out to all the folk that thought Stadia would work:
>
> https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz
> Dave Täht CEO, TekLibre, LLC
> _______________________________________________
> LibreQoS mailing list
> LibreQoS@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/libreqos
>

[-- Attachment #2: Type: text/html, Size: 3335 bytes --]

Re: [LibreQoS] how are you doing on ipv4 address supply?

[dan]

[-- Attachment #1: Type: text/plain, Size: 3236 bytes --]

MPLS is great for those that have dedicated engineering staff or hire a
consultant to help out.  It's a real PITA when the business is primarily
techs and they have no idea how to solve an issue.   I've been pushing for
vxlan/evpn or srv6 for a while as a way to simplify the model.  'wisp'
focused gear just isn't there yet though.  high hopes for mikrotik's
support for vxlan to get hardware acceleration.

On Wed, Oct 26, 2022 at 10:05 AM Herbert Wolverson via LibreQoS <
libreqos@lists.bufferbloat.net> wrote:

> Actually had a conversation with our primary upstream provider yesterday
> about IPv6 (and why
> they won't provide it to us). One of their lead engineers, once plied with
> beer, said that every
> time they've deployed it they get 99% of it working well and 1% of things
> mysteriously
> stop working, or go wonky. That was similar to our experience a few years
> ago. It mostly
> helped a lot, but chasing down the "hey, this advertises a v6 address and
> doesn't actually
> support it" issues drove us crazy.
>
> Right now, we don't have enough IPv4 addresses, but that's being
> rectified. We mostly
> do CGNAT and 10.64 addresses in the meantime, with public IPs assigned
> where they
> are needed (mostly through a tunnel setup to avoid subnetting waste).
> Tunnels are a pain,
> but they work (once you chase down all of the MTU issues).
>
> Which reminds me, I have "can we support MPLS?" on my crazy notes list. I
> know that
> Preseem and similar don't try, but we're already reading deeply enough
> into the ethernet
> header that saying "this is an MPLS label, advance 4 bytes", "this is a
> VPLS label, advance
> X (I forget) bytes" looks do-able. [Note, I personally don't enjoy MPLS.
> It's handy when
> you want to pretend to have a flat network on top of a large routed
> network - and some
> WISP consultants absolutely swear by it - but my experience is that you
> are adding
> complexity for the sake of it. Routing works remarkably well.]
>
> On Tue, Oct 25, 2022 at 10:30 PM Dave Taht via LibreQoS <
> libreqos@lists.bufferbloat.net> wrote:
>
>> in my continued rip-van-winkle, living in the third world (california)
>> way, I am curious as to how y'all are managing your
>> ipv4 address supply and if you are deploying ipv6 to any extent?
>>
>> In all this discussion of multi-gbit fiber, my own direct experience
>> is that AT&T's fiber rollout had very flaky ipv6, and more and more
>> services (like starlink) are appearing behind cgnats, which have their
>> own capex and opex costs.
>>
>> I see a lot of rfc1918 being used as the operational overlay
>> elsewhere, tons of tunnels, also.
>>
>> --
>> This song goes out to all the folk that thought Stadia would work:
>>
>> https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz
>> Dave Täht CEO, TekLibre, LLC
>> _______________________________________________
>> LibreQoS mailing list
>> LibreQoS@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/libreqos
>>
> _______________________________________________
> LibreQoS mailing list
> LibreQoS@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/libreqos
>

[-- Attachment #2: Type: text/html, Size: 4521 bytes --]

Re: [LibreQoS] how are you doing on ipv4 address supply?

[Robert Chacón]

[-- Attachment #1: Type: text/plain, Size: 4274 bytes --]

We use MPLS (VPLS tunnels back to core) with L2 isolation and DHCP snooping
everywhere.
It decapsulates at our core so we don't need MPLS parsing for LibreQoS in
our case.
It works well and minimizes the number of RFC6598 CG-NAT clients behind
public addresses.
I'd prefer simple routing, but with IPv4 exhaustion - that would lead to a
lot of unused RFC6598 addresses (and hence high CG-NAT ratios).
Many clients on one CG-NAT address leads to a lot of problems with services
like Amazon Prime.
I'm hopeful we can switch to VXLAN as Dan suggested. It could be a great
alternative to VPLS/MPLS.

On Wed, Oct 26, 2022 at 10:49 AM dan via LibreQoS <
libreqos@lists.bufferbloat.net> wrote:

> MPLS is great for those that have dedicated engineering staff or hire a
> consultant to help out.  It's a real PITA when the business is primarily
> techs and they have no idea how to solve an issue.   I've been pushing for
> vxlan/evpn or srv6 for a while as a way to simplify the model.  'wisp'
> focused gear just isn't there yet though.  high hopes for mikrotik's
> support for vxlan to get hardware acceleration.
>
> On Wed, Oct 26, 2022 at 10:05 AM Herbert Wolverson via LibreQoS <
> libreqos@lists.bufferbloat.net> wrote:
>
>> Actually had a conversation with our primary upstream provider yesterday
>> about IPv6 (and why
>> they won't provide it to us). One of their lead engineers, once plied
>> with beer, said that every
>> time they've deployed it they get 99% of it working well and 1% of things
>> mysteriously
>> stop working, or go wonky. That was similar to our experience a few years
>> ago. It mostly
>> helped a lot, but chasing down the "hey, this advertises a v6 address and
>> doesn't actually
>> support it" issues drove us crazy.
>>
>> Right now, we don't have enough IPv4 addresses, but that's being
>> rectified. We mostly
>> do CGNAT and 10.64 addresses in the meantime, with public IPs assigned
>> where they
>> are needed (mostly through a tunnel setup to avoid subnetting waste).
>> Tunnels are a pain,
>> but they work (once you chase down all of the MTU issues).
>>
>> Which reminds me, I have "can we support MPLS?" on my crazy notes list. I
>> know that
>> Preseem and similar don't try, but we're already reading deeply enough
>> into the ethernet
>> header that saying "this is an MPLS label, advance 4 bytes", "this is a
>> VPLS label, advance
>> X (I forget) bytes" looks do-able. [Note, I personally don't enjoy MPLS.
>> It's handy when
>> you want to pretend to have a flat network on top of a large routed
>> network - and some
>> WISP consultants absolutely swear by it - but my experience is that you
>> are adding
>> complexity for the sake of it. Routing works remarkably well.]
>>
>> On Tue, Oct 25, 2022 at 10:30 PM Dave Taht via LibreQoS <
>> libreqos@lists.bufferbloat.net> wrote:
>>
>>> in my continued rip-van-winkle, living in the third world (california)
>>> way, I am curious as to how y'all are managing your
>>> ipv4 address supply and if you are deploying ipv6 to any extent?
>>>
>>> In all this discussion of multi-gbit fiber, my own direct experience
>>> is that AT&T's fiber rollout had very flaky ipv6, and more and more
>>> services (like starlink) are appearing behind cgnats, which have their
>>> own capex and opex costs.
>>>
>>> I see a lot of rfc1918 being used as the operational overlay
>>> elsewhere, tons of tunnels, also.
>>>
>>> --
>>> This song goes out to all the folk that thought Stadia would work:
>>>
>>> https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz
>>> Dave Täht CEO, TekLibre, LLC
>>> _______________________________________________
>>> LibreQoS mailing list
>>> LibreQoS@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/libreqos
>>>
>> _______________________________________________
>> LibreQoS mailing list
>> LibreQoS@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/libreqos
>>
> _______________________________________________
> LibreQoS mailing list
> LibreQoS@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/libreqos
>


-- 
Robert Chacón
CEO | JackRabbit Wireless LLC <http://jackrabbitwireless.com>

[-- Attachment #2: Type: text/html, Size: 6124 bytes --]

Re: [LibreQoS] how are you doing on ipv4 address supply?

[Herbert Wolverson]

[-- Attachment #1: Type: text/plain, Size: 5238 bytes --]

The main reason I was asking about MPLS is that it looks pretty easy to
extract the data, and I've seen a bunch of people on the WISP Talk FB group
complaining about having to de-encapsulate before they pass things through
Preseem. Where I could see that being most useful is if you have a shaper
at a tower (rather than just the one), and want to shape your backhaul
directly. I'll keep it on the "things to play with" list. :-)

We ran MPLS/VPLS for a while; we were pretty surprised when our network
sped up a lot when it was removed! (Routers got really good at routing, and
it's often faster than parsing a label these days). It also made it easier
for the other techs to diagnose faults, MPLS never seemed to "click" for
them.

On Wed, Oct 26, 2022 at 2:15 PM Robert Chacón <
robert.chacon@jackrabbitwireless.com> wrote:

> We use MPLS (VPLS tunnels back to core) with L2 isolation and DHCP
> snooping everywhere.
> It decapsulates at our core so we don't need MPLS parsing for LibreQoS in
> our case.
> It works well and minimizes the number of RFC6598 CG-NAT clients behind
> public addresses.
> I'd prefer simple routing, but with IPv4 exhaustion - that would lead to a
> lot of unused RFC6598 addresses (and hence high CG-NAT ratios).
> Many clients on one CG-NAT address leads to a lot of problems with
> services like Amazon Prime.
> I'm hopeful we can switch to VXLAN as Dan suggested. It could be a great
> alternative to VPLS/MPLS.
>
> On Wed, Oct 26, 2022 at 10:49 AM dan via LibreQoS <
> libreqos@lists.bufferbloat.net> wrote:
>
>> MPLS is great for those that have dedicated engineering staff or hire a
>> consultant to help out.  It's a real PITA when the business is primarily
>> techs and they have no idea how to solve an issue.   I've been pushing for
>> vxlan/evpn or srv6 for a while as a way to simplify the model.  'wisp'
>> focused gear just isn't there yet though.  high hopes for mikrotik's
>> support for vxlan to get hardware acceleration.
>>
>> On Wed, Oct 26, 2022 at 10:05 AM Herbert Wolverson via LibreQoS <
>> libreqos@lists.bufferbloat.net> wrote:
>>
>>> Actually had a conversation with our primary upstream provider yesterday
>>> about IPv6 (and why
>>> they won't provide it to us). One of their lead engineers, once plied
>>> with beer, said that every
>>> time they've deployed it they get 99% of it working well and 1% of
>>> things mysteriously
>>> stop working, or go wonky. That was similar to our experience a few
>>> years ago. It mostly
>>> helped a lot, but chasing down the "hey, this advertises a v6 address
>>> and doesn't actually
>>> support it" issues drove us crazy.
>>>
>>> Right now, we don't have enough IPv4 addresses, but that's being
>>> rectified. We mostly
>>> do CGNAT and 10.64 addresses in the meantime, with public IPs assigned
>>> where they
>>> are needed (mostly through a tunnel setup to avoid subnetting waste).
>>> Tunnels are a pain,
>>> but they work (once you chase down all of the MTU issues).
>>>
>>> Which reminds me, I have "can we support MPLS?" on my crazy notes list.
>>> I know that
>>> Preseem and similar don't try, but we're already reading deeply enough
>>> into the ethernet
>>> header that saying "this is an MPLS label, advance 4 bytes", "this is a
>>> VPLS label, advance
>>> X (I forget) bytes" looks do-able. [Note, I personally don't enjoy MPLS.
>>> It's handy when
>>> you want to pretend to have a flat network on top of a large routed
>>> network - and some
>>> WISP consultants absolutely swear by it - but my experience is that you
>>> are adding
>>> complexity for the sake of it. Routing works remarkably well.]
>>>
>>> On Tue, Oct 25, 2022 at 10:30 PM Dave Taht via LibreQoS <
>>> libreqos@lists.bufferbloat.net> wrote:
>>>
>>>> in my continued rip-van-winkle, living in the third world (california)
>>>> way, I am curious as to how y'all are managing your
>>>> ipv4 address supply and if you are deploying ipv6 to any extent?
>>>>
>>>> In all this discussion of multi-gbit fiber, my own direct experience
>>>> is that AT&T's fiber rollout had very flaky ipv6, and more and more
>>>> services (like starlink) are appearing behind cgnats, which have their
>>>> own capex and opex costs.
>>>>
>>>> I see a lot of rfc1918 being used as the operational overlay
>>>> elsewhere, tons of tunnels, also.
>>>>
>>>> --
>>>> This song goes out to all the folk that thought Stadia would work:
>>>>
>>>> https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz
>>>> Dave Täht CEO, TekLibre, LLC
>>>> _______________________________________________
>>>> LibreQoS mailing list
>>>> LibreQoS@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/libreqos
>>>>
>>> _______________________________________________
>>> LibreQoS mailing list
>>> LibreQoS@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/libreqos
>>>
>> _______________________________________________
>> LibreQoS mailing list
>> LibreQoS@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/libreqos
>>
>
>
> --
> Robert Chacón
> CEO | JackRabbit Wireless LLC <http://jackrabbitwireless.com>
>

[-- Attachment #2: Type: text/html, Size: 7315 bytes --]

Re: [LibreQoS] how are you doing on ipv4 address supply?

[Robert Chacón]

[-- Attachment #1: Type: text/plain, Size: 6212 bytes --]

I think it could definitely be helpful. Cambium's Bequant-based QoE handles
MPLS parsing.
Like you said MPLS tends to be a holdup for a lot of people looking at
Preseem.
And it would make shaping at sites possible.
You said it looks reasonably straightforward to implement within
cpumap-pping/xdp-cpumap-tc?
If you'd need more time to dedicate to it to explore that more, let us know
what a fair feature bounty would be for it. =) I can see it helping a lot
of operators.

On Wed, Oct 26, 2022 at 1:33 PM Herbert Wolverson via LibreQoS <
libreqos@lists.bufferbloat.net> wrote:

> The main reason I was asking about MPLS is that it looks pretty easy to
> extract the data, and I've seen a bunch of people on the WISP Talk FB group
> complaining about having to de-encapsulate before they pass things through
> Preseem. Where I could see that being most useful is if you have a shaper
> at a tower (rather than just the one), and want to shape your backhaul
> directly. I'll keep it on the "things to play with" list. :-)
>
> We ran MPLS/VPLS for a while; we were pretty surprised when our network
> sped up a lot when it was removed! (Routers got really good at routing, and
> it's often faster than parsing a label these days). It also made it easier
> for the other techs to diagnose faults, MPLS never seemed to "click" for
> them.
>
> On Wed, Oct 26, 2022 at 2:15 PM Robert Chacón <
> robert.chacon@jackrabbitwireless.com> wrote:
>
>> We use MPLS (VPLS tunnels back to core) with L2 isolation and DHCP
>> snooping everywhere.
>> It decapsulates at our core so we don't need MPLS parsing for LibreQoS in
>> our case.
>> It works well and minimizes the number of RFC6598 CG-NAT clients behind
>> public addresses.
>> I'd prefer simple routing, but with IPv4 exhaustion - that would lead to
>> a lot of unused RFC6598 addresses (and hence high CG-NAT ratios).
>> Many clients on one CG-NAT address leads to a lot of problems with
>> services like Amazon Prime.
>> I'm hopeful we can switch to VXLAN as Dan suggested. It could be a great
>> alternative to VPLS/MPLS.
>>
>> On Wed, Oct 26, 2022 at 10:49 AM dan via LibreQoS <
>> libreqos@lists.bufferbloat.net> wrote:
>>
>>> MPLS is great for those that have dedicated engineering staff or hire a
>>> consultant to help out.  It's a real PITA when the business is primarily
>>> techs and they have no idea how to solve an issue.   I've been pushing for
>>> vxlan/evpn or srv6 for a while as a way to simplify the model.  'wisp'
>>> focused gear just isn't there yet though.  high hopes for mikrotik's
>>> support for vxlan to get hardware acceleration.
>>>
>>> On Wed, Oct 26, 2022 at 10:05 AM Herbert Wolverson via LibreQoS <
>>> libreqos@lists.bufferbloat.net> wrote:
>>>
>>>> Actually had a conversation with our primary upstream provider
>>>> yesterday about IPv6 (and why
>>>> they won't provide it to us). One of their lead engineers, once plied
>>>> with beer, said that every
>>>> time they've deployed it they get 99% of it working well and 1% of
>>>> things mysteriously
>>>> stop working, or go wonky. That was similar to our experience a few
>>>> years ago. It mostly
>>>> helped a lot, but chasing down the "hey, this advertises a v6 address
>>>> and doesn't actually
>>>> support it" issues drove us crazy.
>>>>
>>>> Right now, we don't have enough IPv4 addresses, but that's being
>>>> rectified. We mostly
>>>> do CGNAT and 10.64 addresses in the meantime, with public IPs assigned
>>>> where they
>>>> are needed (mostly through a tunnel setup to avoid subnetting waste).
>>>> Tunnels are a pain,
>>>> but they work (once you chase down all of the MTU issues).
>>>>
>>>> Which reminds me, I have "can we support MPLS?" on my crazy notes list.
>>>> I know that
>>>> Preseem and similar don't try, but we're already reading deeply enough
>>>> into the ethernet
>>>> header that saying "this is an MPLS label, advance 4 bytes", "this is a
>>>> VPLS label, advance
>>>> X (I forget) bytes" looks do-able. [Note, I personally don't enjoy
>>>> MPLS. It's handy when
>>>> you want to pretend to have a flat network on top of a large routed
>>>> network - and some
>>>> WISP consultants absolutely swear by it - but my experience is that you
>>>> are adding
>>>> complexity for the sake of it. Routing works remarkably well.]
>>>>
>>>> On Tue, Oct 25, 2022 at 10:30 PM Dave Taht via LibreQoS <
>>>> libreqos@lists.bufferbloat.net> wrote:
>>>>
>>>>> in my continued rip-van-winkle, living in the third world (california)
>>>>> way, I am curious as to how y'all are managing your
>>>>> ipv4 address supply and if you are deploying ipv6 to any extent?
>>>>>
>>>>> In all this discussion of multi-gbit fiber, my own direct experience
>>>>> is that AT&T's fiber rollout had very flaky ipv6, and more and more
>>>>> services (like starlink) are appearing behind cgnats, which have their
>>>>> own capex and opex costs.
>>>>>
>>>>> I see a lot of rfc1918 being used as the operational overlay
>>>>> elsewhere, tons of tunnels, also.
>>>>>
>>>>> --
>>>>> This song goes out to all the folk that thought Stadia would work:
>>>>>
>>>>> https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz
>>>>> Dave Täht CEO, TekLibre, LLC
>>>>> _______________________________________________
>>>>> LibreQoS mailing list
>>>>> LibreQoS@lists.bufferbloat.net
>>>>> https://lists.bufferbloat.net/listinfo/libreqos
>>>>>
>>>> _______________________________________________
>>>> LibreQoS mailing list
>>>> LibreQoS@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/libreqos
>>>>
>>> _______________________________________________
>>> LibreQoS mailing list
>>> LibreQoS@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/libreqos
>>>
>>
>>
>> --
>> Robert Chacón
>> CEO | JackRabbit Wireless LLC <http://jackrabbitwireless.com>
>>
> _______________________________________________
> LibreQoS mailing list
> LibreQoS@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/libreqos
>


-- 
Robert Chacón
CEO | JackRabbit Wireless LLC <http://jackrabbitwireless.com>

[-- Attachment #2: Type: text/html, Size: 8801 bytes --]

Re: [LibreQoS] how are you doing on ipv4 address supply?

[Dave Taht]

In my case, I'd like to go all-in on ipv6 again. It's been 14 years
since I last tried.

There's an earlier RFC for this concept for ospf I think, and an open
bug with mikrottik on that...

https://datatracker.ietf.org/doc/rfc9229/

Re: [LibreQoS] how are you doing on ipv4 address supply?

[Dave Taht]

On the ipv4 address supply issue, ardc funded itself by selling off
part of their 44/8 block. The US government has 14, at least 2 of
which I'm pretty sure they aren't using. There was a rider in some
bill in 2019 that asked the DoD to sell off what blocks they weren't
using, that didn't get past the senate.

I was thinking of politicing as part of a BEAD2 to have a bill that
asked those agencies to sell them off on the open market, and also
create incentives for those holding onto big blocks they aren't using
(cough, apple), to finally put them up as well. I had thought that
once the asking price cracked 50 bucks an IP we'd see more big blocks
appear on the market but so far, no luck. 100 bucks? Don't know...

I've also taken a lot of heat, over the last 6 years, for the other ideas in the
IPv4 Unicast extensions project. Back then John Gilmore convinced me that
240/4 was almost entirely usable as most of the needed patches had
landed in 2008 and it turned out he was correct - I spent a couple
weekends making sure it worked right in linux and BSD, got those
packages up stream, and also fixed up the major routing protocols,
scanned all the open source code in the world for where 240/4 was
specifically blocked (it isn't in any of the dpdk or iot stacks).

Along the way, I also made 0/8 work in linux.

To say that our proposals to finally make those generally usable over,
say, the next 10 years, was met with enthusiasm by the powers-that-be,
would be lying. Oh, man, in particular our proposal to make 127/8
virtual-host-wide ip address space to solve some horrible problems k8
introduced generated more flamage than I care to think about - but
that made the idea of 240/4 seem almost like a no-brainer to more
people, so there's that.

https://www.ietf.org/id/draft-schoen-intarea-unicast-240-03.html

Recently did a study showing how far 240/4 usually got within an ISP
via the atlas probes before it hit a bogon file.

Re: [LibreQoS] how are you doing on ipv4 address supply?

[Toke Høiland-Jørgensen]

Robert Chacón via LibreQoS <libreqos@lists.bufferbloat.net> writes:

> I'd prefer simple routing, but with IPv4 exhaustion - that would lead to a
> lot of unused RFC6598 addresses (and hence high CG-NAT ratios).

Note that it's possible to route IPv4 traffic over an IPv6-only backhaul
(at least with Linux gear):

# ip r add 10.0.0.1 via inet6 fe80::1 dev wg0
# ip r | grep 10.0.0.1
10.0.0.1 via inet6 fe80::1 dev wg0

There's an (expired, unfortunately; we should fix that) IETF draft
describing the general mechanism:
https://www.ietf.org/archive/id/draft-chroboczek-int-v4-via-v6-01.html

And an extension for the Babel routing protocol to implement this (so
you can route v4 traffic through a whole network without assigning
anything other than v6 link-local addresses to the intermediate nodes):

https://datatracker.ietf.org/doc/html/rfc9229

-Toke

Re: [LibreQoS] how are you doing on ipv4 address supply?

[dan]

[-- Attachment #1: Type: text/plain, Size: 1367 bytes --]

IPv6 next-hops can be distributed in OSPF and BGP in mikrotik as well, but
it's maybe not 100% ready for prime time.

Streaming services essentially all support IPv6 so that's a big win.  As is
gaming services.  Maybe general web browsing and other odd apps have some
teething to do still but I think we're pretty much ready for dual stack
right now.

On Wed, Oct 26, 2022 at 2:52 PM Toke Høiland-Jørgensen <toke@toke.dk> wrote:

> Robert Chacón via LibreQoS <libreqos@lists.bufferbloat.net> writes:
>
> > I'd prefer simple routing, but with IPv4 exhaustion - that would lead to
> a
> > lot of unused RFC6598 addresses (and hence high CG-NAT ratios).
>
> Note that it's possible to route IPv4 traffic over an IPv6-only backhaul
> (at least with Linux gear):
>
> # ip r add 10.0.0.1 via inet6 fe80::1 dev wg0
> # ip r | grep 10.0.0.1
> 10.0.0.1 via inet6 fe80::1 dev wg0
>
> There's an (expired, unfortunately; we should fix that) IETF draft
> describing the general mechanism:
> https://www.ietf.org/archive/id/draft-chroboczek-int-v4-via-v6-01.html
>
> And an extension for the Babel routing protocol to implement this (so
> you can route v4 traffic through a whole network without assigning
> anything other than v6 link-local addresses to the intermediate nodes):
>
> https://datatracker.ietf.org/doc/html/rfc9229
>
> -Toke
>

[-- Attachment #2: Type: text/html, Size: 2017 bytes --]