Validate IP Addresses and Networks with ipaddress

Select a timestamp to watch that moment on YouTube.

1. 00:00

   IP addresses look like strings, so it is tempting to validate them or check membership with string methods. That leads to mistakes. The text `192.0.2.10` begins with `192.0.2.1`, but it is a different address. Network ranges also have bit boundaries that are not obvious from decimal prefixes. Python's `ipaddress` module parses addresses and networks into objects that understand those boundaries. We will first reproduce a false match, then use `ip_address` and `ip_network` to check actual membership. After that, we will make a small function that rejects invalid input rather than silently guessing.

2. 00:42

   Our examples use documentation address ranges, not an actual network service. We do not connect to any host. One more caution: deciding whether an address belongs to a network is only one piece of access control. A production system must also decide which peer address is trustworthy, especially behind proxies. For this lesson we focus on representing and validating addresses correctly before any policy decision is made. The first candidate is exactly the allowed host. The second has one extra zero at the end, but `startswith` only compares text from the beginning. It does not know where one address component ends or what a network mask

3. 01:24

   means. If this check controlled a sensitive action, the false match would be a real defect. Switching to `split('.')` and comparing pieces by hand may fix this single example, but it still leaves address validation, IPv6, and network masks for us to reimplement. A textual prefix like `192.0.2.` happens to describe a familiar group of IPv4 addresses, but it is not a general implementation of CIDR network membership. It also does not reject invalid forms such as a component outside the allowed range. Instead, parse the input. If parsing fails, treat it as invalid.

4. 02:06

   If parsing succeeds, compare address objects or ask whether an address is contained in a network object. The standard library already knows the rules for both IPv4 and IPv6. The two parsed addresses are different objects representing different numeric addresses. Both belong to the same /24 network, which has 256 possible IPv4 addresses. That makes the distinction explicit: exact host equality asks a narrower question than network membership. A network with a /32 prefix would contain only one IPv4 address. The mask size is part of the policy, not a textual convenience.

5. 02:47

   The `ipaddress` module also supports IPv6 objects, so the same basic pattern applies without splitting on colons yourself. The call `ip_network` is strict by default about host bits in a network address. For example, `192.0.2.1/24` is a host with a mask, not the canonical network base, and strict parsing will reject it. Use `strict=False` only when you deliberately want the module to normalize that input to its containing network. In a validation path, silently normalizing a surprising value can hide a configuration error, so decide what the caller is allowed to supply.

6. 03:28

   The function converts both inputs before making a decision. If either value is malformed, it raises a clear validation error and preserves the original cause. If the address and network have different versions, such as IPv4 versus IPv6, membership is False. Otherwise it delegates containment to the parsed network. Our first example belongs to the documentation /24 range; the second is outside it. The result is a Boolean based on actual address bits, not a decimal string prefix. In a real service, you would build the allowed network objects once from trusted configuration rather than reparsing them for every request.

7. 04:10

   You would also carefully determine the true remote peer address. Headers supplied by clients can be spoofed unless a trusted proxy has established them. This helper does not claim to solve those deployment questions; it solves the local parsing and membership task. Keeping that boundary narrow makes it easier to test and reuse. The /32 test catches the false match from the beginning: `192.0.2.10` is not the host `192.0.2.1`. We also test an IPv6 documentation address inside an IPv6 range and a mixed-version check that must return False. Finally, the address with 999 in one component is invalid and raises

8. 04:52

   `ValueError`. Catching it in the test confirms that bad data is rejected, not accepted after a string comparison. On the site, change the prefix from /32 to /24 and predict which assertion changes. Then try a different IPv6 prefix and observe the containment rule. Be precise about the question you ask: exact host identity, membership in a network, and validity of the input are three separate checks. Parsed objects make those differences visible in code. Complete the practice task by replacing a misleading textual test with an explicit network rule and at least one negative case.