IP addressing, routing, and ports

Record the addresses, routes, ports and connection direction used by each service. Verify the responding device and its identity separately.

Overview#

An address locates an interface in a routing context; it isn't a durable device identity or an authorisation claim. A port identifies a transport endpoint convention; it doesn't prove which protocol, version, or peer is present.

Address categories#

• IPv4 private use space is defined by RFC 1918; it isn't inherently trusted or globally unique.
• IPv6 unique local addresses are defined by RFC 4193; link local addresses have interface scope and often need a zone identifier in software.
• Documentation must use RFC 5737 IPv4 ranges and RFC 3849 IPv6 space, not plausible customer networks.
• Loopback is appropriate only when the entire example is local and no device connectivity is implied.

Inventory address assignment source, static, DHCP reservation, dynamic DHCP, SLAAC, vendor discovery, or cloud enrolment, and the recovery procedure when it changes.

Routing and zones#

Route only the flows the architecture requires. A typical flow record contains:

source_zone: video-edge
source_role: camera
destination_service: vms-ingest.example
address_family: dual-stack
transport: tcp
destination_port: product-documented
initiator: camera
protection: tls-with-server-auth
purpose: event-and-health-uplink
availability: locally-buffered-for-30-minutes
owner: video-platform-team

Prefer service identity and named policy objects where tooling supports them, while retaining resolved address observability. Avoid broad “camera VLAN to server VLAN” permissions that silently expose management and control interfaces.

Ports#

IANA maintains the Service Name and Transport Protocol Port Number Registry. Registered numbers are references, not universal product facts. Products may use configurable or dynamic ports; protocols such as RTP can negotiate media ports; TLS may protect a service on either a conventional or product specific port.

For each port, record direction and initiation. A firewall rule written as “allow 443” is incomplete without source/destination, TCP/UDP, IP version, purpose, TLS identity, and whether return traffic is stateful.

NAT and port forwarding#

Network Address Translation changes addressing and often blocks inbound initiation; it doesn't authenticate, authorise, or encrypt. Avoid exposing device management or media interfaces by generic port forwarding. Prefer authenticated outbound device connections, a managed application proxy, or an approved remote access boundary with strong identity and logging.

Protocols embedding addresses or opening negotiated secondary connections need NAT aware design. Discovery multicast usually doesn't cross routers/NAT without an explicit proxy or gateway, and extending it can widen spoofing/exposure.

DNS and certificates#

Separate device hostname, service discovery name, certificate identity, and display name. If TLS uses DNS identity, certificate names and DNS lifecycle must be coordinated. Define behaviour for stale cache, split horizon views, multiple addresses, failover, DNSSEC where used, and resolver outage.

Don't infer#

• An open port isn't proof of a service.
• A closed port isn't proof a feature is absent; it may be disabled or outbound only.
• Same subnet isn't authorisation.
• Private address isn't confidentiality.
• Reachability isn't health, and health isn't safe physical operation.

Section overview · Wiki home