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.