These DNS names and IP ranges are reserved (on the Internet) for use in examples, documentation and similar. As such, they are not available for assignment on the Internet and also should not be assigned on local networks that require proper Internet connectivity.

Because these DNS names and IP ranges are reserved specifically for example and documentation purposes, they can be used freely in anonymizing network assignments without risk of accidentally referring to some other real-world entity’s actual assignment either at the present time or in the future.

DNS names

RFC 2606 reserves four top-level domain names:

  • test
  • example
  • invalid
  • localhost

RFC 2606 also reserves three second-level domain names:


IPv4 networks

RFC 5737 reserves three IPv4 network address blocks out of the IPv4 globally routable unicast space:

  • ( – (originally by the now obsolete RFC 1166)
  • ( –
  • ( –

For a local network that requires Internet connectivity, use either a netblock carved out of one of the RFC 1918 address blocks or globally routable addresses.

IPv6 networks

RFC 3849 reserves a single IPv6 network address block out of the IPv6 globally routable unicast space:

  • 2001:DB8::/32

For a local network that requires Internet connectivity, use either globally routable addresses or a netblock assigned as described in RFC 4193 sections 3.1 and 3.2.2 using FC00::/7 space.

EUI-48 and EUI-64 MAC addresses

Note that MAC addresses are normally not routed outside of the local subnet, but they can be used to generate particularly IPv6 addresses and as such may be exposed directly or indirectly on a larger network. For example, RFC 2464 defines stateless IPv6 address autoconfiguration for link-local addresses based on the EUI-64 address of a network interface, and RFC 4193 uses an EUI-64 identifier in the process of generating a unique local IPv6 unicast address prefix. Particularly in cases where the EUI-48 or EUI-64 identifier is used directly, such as in RFC 2464, addresses generated based on the ranges reserved for use in documentation should also be safe to use in documentation and examples. As discussed in for example RFC 4941 and RFC 7217, for several reasons, use of the EUI-48 or EUI-64 identifier directly should be avoided on actual networks.

RFC 7042 reserves two EUI-48 ranges for use in documentation:

  • 00-00-5E-00-53-00 through 00-00-5E-00-53-FF for unicast
  • 01-00-5E-90-10-00 through 01-00-5E-90-10-FF for multicast

RFC 7042 also reserves several unicast EUI-64 ranges for use in documentation:

  • 00-00-5E-EF-10-00-00-00 through 00-00-5E-EF-10-00-00-FF
  • 00-00-5E-FE-C0-00-02-00 through 00-00-5E-FE-C0-00-02-FF
  • 00-00-5E-FE-C6-33-64-00 through 00-00-5E-FE-C6-33-64-FF
  • 00-00-5E-FE-CB-00-71-00 through 00-00-5E-FE-CB-00-71-FF
  • 00-00-5E-FF-FE-00-53-00 through 00-00-5E-FF-FE-00-53-FF
  • 00-00-5E-FE-EA-C0-00-02 (specific EUI-64 address)
  • 00-00-5E-FE-EA-C6-33-64 (specific EUI-64 address)
  • 00-00-5E-FE-EA-CB-00-71 (specific EUI-64 address)

RFC 7042 also reserves several multicast EUI-64 ranges for use in documentation:

  • 01-00-5E-EF-10-00-00-00 through 01-00-5E-EF-10-00-00-FF
  • 01-00-5E-FE-C0-00-02-00 through 01-00-5E-FE-C0-00-02-FF
  • 01-00-5E-FE-C6-33-64-00 through 01-00-5E-FE-C6-33-64-FF
  • 01-00-5E-FE-CB-00-71-00 through 01-00-5E-FE-CB-00-71-FF
  • 01-00-5E-FE-EA-C0-00-02 (specific EUI-64 address)
  • 01-00-5E-FE-EA-C6-33-64 (specific EUI-64 address)
  • 01-00-5E-FE-EA-CB-00-71 (specific EUI-64 address)