Running i2pd (and Java I2P) behind DS-Lite gives you NTCP2v6 and SSUv6 with corresponding addresses published. IPv4 remains in status "Testing" forever. You get a few dozen transit tunnels with total traffic below 1kBps average. Your local traffic sticks out by a factor of 100-1000. This is a serious bug, since new residential internet connections are usually rolled out over gigabit capable fiber or cable utilizing DS-Lite.
DS-Lite routes IPv4 via IPv6 through an AFTR-Gateway and then Carrier Grade-NAT. In this situation IPv4 should be handled as "firewalled", but i2p(d) fails. Pointing to correct values does not help (nat=true; upnp=false; mtu4=1390 and the like). Your mileage may vary, simply because your provider might have a different configuration for AFTR and CGNAT.
Adding a second IPv4 interface like a Wireguard VPN makes i2pd properly work as firewalled over IPv4 and traffic goes up considerably. If you do not run a VPN or do not want to use it this way, then there a way out: Tell i2pd the hard way, it is firewalled, by using a proxy.
Scenario 1: Proxy for TCP and UDP. i2pd shows false addresses for SSU2 (suppress with published = false). Will employ outbound connections for SSU2v4, NTCP2v4 and NTCP2v6, no SSU2v6.
Scenario 2: Proxy for TCP only. i2pd shows false addresses for NTCP2v6 (suppress with published = false) and SSU2v4 (must tolerate). Will employ outbound connections for NTCP2v4/6 and is fully reachable using SSU2v6, no SSU2v4.
I prefer scenario 2, already more than 1000 transit tunnels after 2 hours uptime. Tried multiple proxies, Dante did not work, socks (from 3proxy) quits. This simple command helps, if you run Debian or compile yourself:
ulimit -n 4096; microsocks