docs: add network ip masquerade example

[lsh1215]

What changed

Added a small docker network create example showing how to configure IP masquerading for a custom bridge network with --opt com.docker.network.bridge.enable_ip_masquerade=false.

Why

This follows up on docker/docs#13861. The existing table maps com.docker.network.bridge.enable_ip_masquerade to the --ip-masq daemon option for the default docker0 bridge, but it does not directly show the equivalent docker network create command for a custom bridge network.

Related issue status

#5599 already improved this section by clarifying that --ip-masq is a daemon option for the default docker0 bridge. This PR adds a direct example for configuring the equivalent bridge driver option when creating a custom bridge network.

If maintainers consider #5599 sufficient for docker/docs#13861, then the issue may only need a status decision rather than this follow-up change.

Validation

• make -f docker.Makefile mddocs
• make -f docker.Makefile yamldocs
• git diff --check

Notes

This is a documentation-only change. It does not change Docker CLI or daemon behavior.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[docker-agent]

Assessment: 🟢 APPROVE

[docker-agent]

Assessment: 🟢 APPROVE

[docker-agent]

Assessment: 🟢 APPROVE

[docker-agent]

Assessment: 🟢 APPROVE

[docker-agent]

Assessment: 🟢 APPROVE

This is a clean, well-placed documentation addition. The new example correctly demonstrates the com.docker.network.bridge.enable_ip_masquerade option using the proper --opt flag syntax, consistent with the bridge driver options table immediately above it. Code fence style and indentation match the rest of the file.

The drafter raised a concern that omitting --subnet could mislead readers into creating a network with broken outbound connectivity. The verifier dismissed this: the file already uses minimal examples without --subnet elsewhere (e.g. line 44), the example demonstrates a specific option rather than providing a production-ready setup, and disabling masquerade is valid in multiple topologies (e.g. when the host is the router). No in-scope bugs were found.

[lsh1215]

Friendly ping 🙂 Just checking in on this one — it's a small docs-only change (adding an IP-masquerade example to network create). All CI checks are green except validate-milestone, which needs a maintainer to set the milestone.

@thaJeztah whenever you have a spare moment, could you take a look? No rush at all, and happy to rebase or adjust if anything's needed. Thanks! 🙏

[dvdksn]

I don't think this is the right place/format for this. We already explain the option in the table above. I think what's missing if anything is to explain how these options are set. The introduction to the section currently reads:

When creating a custom bridge network, the following additional options can be passed.

But we don't say how, i.e.

When creating a custom bridge network, you can configure driver options using the --opt flag. The following table lists all configurable driver options for bridge networks: ...

And then below the table we could have a small example showing the exact syntax:

For example, to create a custom bridge network with IP masquerading disabled:

$ docker network create \
    --driver bridge \
    --opt com.docker.network.bridge.enable_ip_masquerade=false \
    no-masq-network

[lsh1215]

Thanks @dvdksn, that makes sense. I've reworked the section along the lines you suggested (force-pushed just now):

• The intro now explains that driver options are set with the --opt flag (I kept the existing note about the equivalent docker0/daemon flags, since the table's second column relies on that context).
• Dropped the redundant enable_ip_masquerade paragraph, so the example now sits directly below the table as a general illustration of setting a bridge driver option.

Regenerated the docs (make mddocs / make yamldocs) — no changes outside the reworked prose. Happy to tweak the wording further if you'd prefer.

[lsh1215]

Reopened as #7117 — this PR couldn't be reopened after the branch was updated while closed. Continuing the review there (same change, addressing @dvdksn's feedback). Apologies for the noise.