From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw1-x112e.google.com (mail-yw1-x112e.google.com [IPv6:2607:f8b0:4864:20::112e]) (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 160D33B2A4 for ; Wed, 26 Oct 2022 18:38:34 -0400 (EDT) Received: by mail-yw1-x112e.google.com with SMTP id 00721157ae682-369c2f83697so156844687b3.3 for ; Wed, 26 Oct 2022 15:38:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=+C4LE6O20xwNhPVMDzW8bQi+BebJGS9j93AvwhKD+tU=; b=mI26FkxLKsin3R7GWDZz/dK+9scxQow/HRiDTNNBJFaCDGW2IHXYlLYKOHJJWpBvpj 4TSrRjw3BWgF/6BrU/+Ln/wrllLjenZ0SmMp8EW285rMQsT+Rl1aQCDo689fwV8a6nUu +qAqqnQXNg7ADQF0cBmammJQ68ljtDDZHDrpYf6W/AgJbvHg21FZM5DUdo/Gt8Z6fHQ8 6BKqCKRk9yNPHlKssHqFRoLrMQwxYCTbESIh+d1K/HH5KWnNZi1TevnQgxxjEDnmgxa3 QtCLR/YnNFxF20XjqjO7TJQ4La0ZwbCZgh2HhqbzLkTTHsWBWlHtcD+QyQ53x6nFL6qf dERQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=+C4LE6O20xwNhPVMDzW8bQi+BebJGS9j93AvwhKD+tU=; b=h4btcqBHyVDusACFpjWPrPww0qv5aHFYTZ4Qk9xp2LyE3/Q4ltq0kVVi0amahZxCoU J+LzeBHK2rOWhltH0Tz2JOiyTuxxeMf2rAw/GOFIibi591iKr/ALDjgn2N2bxSuzAA/S QJ7QlRKEvXXLSxlElJj0w1eBsc6utpZYAhzZvy3VdAFol1hOGcmCl97oXb9gUYMJWNUM Y6CErympExdLWwDnjOsPVZUK6yPTK5wmHc1G4YzxOErxoHEkwPcgRbKAeeMyGar3UixY y6VfOIx0v5W4mQqy4vA78bjpeZ0hAziMfE4xAcCURY4jLB27JHD0E2106GrPggvT7dTU jS5w== X-Gm-Message-State: ACrzQf0OIfje4bGwifpN3QsB3LvyrfooR51IpQWjw3BuC/4xBOGxg/gN DpsqsgR/ha4dmYblcXYtR+bxeQfavFUDo9pbcaZsDbQls/c= X-Google-Smtp-Source: AMsMyM5XzEwOr72PTHlV4HdCbrdDrKYxyqTt2gSdmgw3FGPeKxXUluAaj1qljSSwt+E2rHHXsd3cr7gmvMPnX0Y04QU= X-Received: by 2002:a81:7993:0:b0:351:b89:2cf8 with SMTP id u141-20020a817993000000b003510b892cf8mr40050960ywc.320.1666823913481; Wed, 26 Oct 2022 15:38:33 -0700 (PDT) MIME-Version: 1.0 References: <87wn8m1f5c.fsf@toke.dk> In-Reply-To: <87wn8m1f5c.fsf@toke.dk> From: dan Date: Wed, 26 Oct 2022 16:38:22 -0600 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: =?UTF-8?Q?Robert_Chac=C3=B3n?= , libreqos@lists.bufferbloat.net Content-Type: multipart/alternative; boundary="000000000000442cce05ebf7aff0" Subject: Re: [LibreQoS] how are you doing on ipv4 address supply? X-BeenThere: libreqos@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Many ISPs need the kinds of quality shaping cake can do List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2022 22:38:34 -0000 --000000000000442cce05ebf7aff0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=C3=B8iland-J=C3=B8rgensen wrote: > Robert Chac=C3=B3n via LibreQoS writes: > > > I'd prefer simple routing, but with IPv4 exhaustion - that would lead t= o > 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 > --000000000000442cce05ebf7aff0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
IPv6 next-hops can be distributed in OSPF and BGP in mikro= tik as well, but it's maybe not 100% ready for prime time.

Streaming services essentially all support IPv6 so that's a big = win.=C2=A0 As is gaming services.=C2=A0 Maybe general web browsing and othe= r 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=C3=B8iland-J=C3=B8rgensen <toke@toke.d= k> wrote:
Robert Chac=C3=B3n via LibreQoS <libreqos@lists.bufferbloat.net> writes= :

> I'd prefer simple routing, but with IPv4 exhaustion - that would l= ead 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 backhau= l
(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/i= d/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
--000000000000442cce05ebf7aff0--