This issue was originally reported against python3-podman:
https://issues.redhat.com/browse/RHEL-70162

However, after research, this issue should be fixed on podman as well.

The test results from QE:

1. systemctl start podman.socket
2. podman network create --subnet 10.89.0.0/16 testnet
3. podman run -d --name testctr quay.io/fedora/fedora:41 sleep infinity
4. Write a python script to make the network connect the container and capture the payload

# cat test.py
import podman
import json

with podman.PodmanClient(base_url="unix:///run/podman/podman.sock") as client:
    net = client.networks.get("testnet")
    ctr = client.containers.get("testctr")

    # Capture the payload
    captured_payload = {}
    original_post = client.api.post
    def capture_post(url, *args, **kwargs):
        if "data" in kwargs:
            captured_payload["data"] = json.loads(kwargs["data"])
        return original_post(url, *args, **kwargs)  # Call the real request

    client.api.post = capture_post

    # Call connect
    net.connect(ctr, ipv4_address="10.89.0.50")

    # Print the captured payload
    print("Captured payload:")
    print(json.dumps(captured_payload["data"], indent=2))

    client.api.post = original_post

5. Run the script; it returns a 0 exit code, and the payload is what we expect

# python test.py
Captured payload:
{
  "Container": "03b86f2a37bed8214e8b361cafc6f980c1b249dbf26a289ae3d7cf7d8da2446d",
  "EndpointConfig": {
    "IPAddress": "10.89.0.50",
    "IPAMConfig": {
      "IPv4Address": "10.89.0.50"
    },
    "NetworkID": "9afbce9f2416520733bacb370315d32b6b2c43d6097576df1c1222859d91eecc"
  }
}

6. Inspect the container to check if the IP is set properly

podman inspect testctr | jq '.[0].NetworkSettings.Networks'
{
  "podman": {
    "EndpointID": "",
    "Gateway": "10.88.0.1",
    "IPAddress": "10.88.0.13",
    "IPPrefixLen": 16,
    "IPv6Gateway": "",
    "GlobalIPv6Address": "",
    "GlobalIPv6PrefixLen": 0,
    "MacAddress": "f2:73:21:fb:5d:ae",
    "NetworkID": "2f259bab93aaaaa2542ba43ef33eb990d0999ee1b9924b557b7be53c0b7a1bb9",
    "DriverOpts": null,
    "IPAMConfig": null,
    "Links": null,
    "Aliases": [
      "03b86f2a37be"
    ]
  },
  "testnet": {
    "EndpointID": "",
    "Gateway": "10.89.0.1",
    "IPAddress": "10.89.0.8",
    "IPPrefixLen": 16,
    "IPv6Gateway": "",
    "GlobalIPv6Address": "",
    "GlobalIPv6PrefixLen": 0,
    "MacAddress": "72:bc:21:1a:3b:b6",
    "NetworkID": "879598ab051f728c6249986ea72d3f3e0ff75e532e83cbbddf8d1f6052be6a30",
    "DriverOpts": null,
    "IPAMConfig": null,
    "Links": null,
    "Aliases": [
      "03b86f2a37be"
    ]
  }
}

We can see testnet is successfully connected to the container, but IP address is not, and "IPAMConfig" is still null

The Dev's comment on this issue:

I want to add some context from my docker-podman-api-sync investigation, specifically something about the IPAMConfig parameter. Docker 1.44 updates IPAMConfig, and applies the effect retroactively for all versions. I believe there are more changes (sometimes the changelogs are incomplete) which are impacting IPAMConfig retroactively.

Quoting from docker docs:
> POST /networks/create now returns a 400 if the IPAMConfig has invalid values. Note that this change is unversioned and applied to all API versions on daemon that support version 1.44.

Now, our docs seem to be documenting the behavior, therefore this fix is not planned as part of 1.44, nor it's tracked anywhere but here. imho this should be fixed as a bug in podman with higher priority than podman-docker api sync.