Port-block allocation (deterministic NAT)

Assigning each subscriber a fixed, predictable block of source ports for the duration of a session, and logging that assignment - rather than logging every individual translation as it happens.

It is the difference between a retention obligation that is affordable and one that is not: logging moves from per-flow to per-session, and attribution becomes arithmetic rather than a search through a flow database. That matters most where the output is a name given to a court, because a defensible answer requires address, port and timestamp together. The trade is that block size caps a subscriber's simultaneous connections, and an undersized block produces failures users report as random network faults.

Two schemes share the name. In RFC 7768's dynamic form the NAT gives a subscriber a block of ports, for example 2001 to 2300, on the first packet, adds another block when needed and writes one log line per block allocated or released, reducing log volume by the block size; it cites 42.5 TB of per-session logs against 40.6 GB with blocks, for 20,000 subscribers over 60 days, about 1,047 to 1. In RFC 7422's deterministic form the block is a function of the inside address, so only configuration changes and overflow blocks need logging.

RFC 7422's example puts 198.51.100.0/28 behind 192.0.2.1 with a dynamic pool factor of 2, a ratio of 1:16, and (65536 minus 1024)/16 = 4032 ports per inside address: subscriber 1 holds 1024 to 5055 and the dynamic pool runs from 57472 to 65535. A report for port 2001 maps straight back to subscriber 1; one for port 58204 lands in the dynamic pool and needs the log. The CGN must keep a record whenever those parameters change.

The trade sits among RFC 6888's three soft goals, port utilisation, log volume and resistance to port guessing, so RFC 7422 asks for random port choice within each block.

Also known as: deterministic nat, port block, pba, log reduction

Sources

← All glossary entries