IPv6 Address Planning for Enterprise Networks - 夜莺博客

IPv6 Address Planning for Enterprise Networks

IPv4 address planning is about scarcity: you count hosts, you subnet tightly, you NAT. IPv6 planning is about structure. The address space is effectively unlimited, which means the design decisions are about hierarchy, aggregation and readability - and a plan that ignores those will produce a routing table that cannot be summarised and an operations team that cannot tell which address belongs to which site.

This article sets out a practical enterprise plan: how to slice a /48, why /64 on a LAN is not optional, what to do about interface identifiers, how to use ULA, and the mistakes that are expensive to correct later.

The Allocation Hierarchy

A typical enterprise receives a /48 from its ISP or regional registry (a /56 from some ISPs; ask for /48). That is 65,536 /64s. Structure it deliberately:

2001:db8:abcd::/48        enterprise aggregate, announced as one prefix
  2001:db8:abcd:0000::/52    reserved / infrastructure
  2001:db8:abcd:0100::/56    site: HQ
  2001:db8:abcd:0200::/56    site: Manchester
  2001:db8:abcd:0300::/56    site: Singapore
  2001:db8:abcd:0400::/56    site: AWS eu-west-1
  2001:db8:abcd:f000::/52    reserved / lab and regional carve-outs

within a site /56 (256 /64s), by function:
  ::0000/64   site infrastructure (loopbacks, point-to-point)
  ::0010/64   management
  ::0020/64   servers, vlan 20
  ::0030/64   servers, vlan 30
  ::0100/64   user vlan 100
  ::0101/64   user vlan 101
  ::0f00/64   guest / BYOD

The point of the nibble boundaries is human readability. An engineer should be able to look at 2001:db8:abcd:0101::/64 and infer "HQ, user VLAN 101". If the plan requires a spreadsheet lookup for every address, it will not be followed during an incident.

Why /64 on a LAN

RFC 4291 defines the 64-bit boundary: a subnet prefix is 64 bits and an interface identifier is 64 bits. Everything about stateless autoconfiguration depends on it. SLAAC requires it, router advertisements assume it, and neighbour discovery works on it. Subnetting a LAN into /80 or /96 segments to "save addresses" breaks SLAAC and creates link-layer weirdness for no benefit - you have 65,536 subnets, and using a /64 for a two-host segment costs nothing that matters.

There are three exceptions worth using:

  • Point-to-point links: /127 (RFC 6164). Two usable addresses, no subnet-router anycast complications, no ping-pong risk on unnumbered-style links.
  • Loopbacks: /128. A single address, which is what a loopback is.
  • Host routes in a routing protocol. Not subnetting - just how a /128 host route appears in the table.
! router-to-router link
interface TenGigabitEthernet0/0/1
 ipv6 address 2001:db8:abcd:0:1::1/127
! loopback
interface Loopback0
 ipv6 address 2001:db8:abcd:0:ffff::1/128
! verify
show ipv6 interface brief
show ipv6 route 2001:db8:abcd::/48

Interface Identifiers

The lower 64 bits can be generated several ways, and the choice is a privacy-versus-predictability trade-off.

Method Form Property
EUI-64 FF:FE inserted into the MAC Predictable, embeds the MAC, poor for privacy
Stable privacy (RFC 7217) Hash of prefix, interface, and a per-host secret Stable per prefix, not linkable across prefixes - the default for most modern clients
Random / temporary Random, rotated Best privacy, useless for server ACLs and monitoring
Fixed / manually assigned Administratively chosen, often ::1 or a meaningful value Best for servers, gateways and anything you address in a policy

The practical rule: let client endpoints use SLAAC with stable privacy addressing, and assign fixed addresses to servers, infrastructure and anything referenced by an ACL. Do not build filtering logic on client addresses - they change, and the same client will have different addresses on different subnets by design.

Where the assignment method is a design decision at all - SLAAC versus stateful DHCPv6, and whether to use DHCPv6 for parameters only - the trade-offs are the same ones set out in this SLAAC vs DHCPv6 guide. The router-side flags that control it are the ones configured with neighbour discovery, as described in this neighbour discovery and RA guide.

ULA: Useful, But Understand What It Is

Unique Local Addresses (fc00::/7, in practice fd00::/8) are the IPv6 answer to RFC 1918, with one important difference: they are not a security boundary. Every device can route them, and there is no NAT in the standard to hide them.

Sensible uses:

  • Stable internal addressing for management and infrastructure, so a change of ISP prefix does not break every internal reference.
  • Lab and isolated environments.
  • Interfaces that genuinely should not be reachable from the internet, used in addition to global addressing rather than instead of it.

Anti-patterns:

  • Using ULA as your only addressing and then NATing it. IPv6 has no NAT requirement; adding it recreates the IPv4 problems you were escaping.
  • Treating ULA as "internal means trusted". Filtering is still required.
  • Using ULA for anything that needs internet reachability without also having a global address.

DNS and Reverse Zones

IPv6 reverse DNS is a nibble-reversed tree under ip6.arpa. For 2001:db8:abcd:0101::/64 the reverse delegation is:

1.0.1.0.0.0.0.0.d.c.b.a.8.b.d.0.1.0.0.2.ip6.arpa

Delegation is by nibble, so a /48 gives you 20 nibbles of delegation freedom. Keep reverse zones aligned with the same boundary as your forward zones, or you will maintain two different hierarchies. If you already have a source of truth holding your IPv4 prefixes and DNS zones, put IPv6 in it before the first address is assigned; retrofitting an address plan into an IPAM system later means reconciling the plan with reality, which is slower and less accurate - the same discipline that makes the workflow in this NetBox IPAM guide useful for IPv4 applies directly.

Common Planning Mistakes

  1. Using a /64 for the whole site. It looks generous and it is a trap: you get one subnet and cannot add a VLAN without renumbering.
  2. Subnetting below /64 to "save space". Breaks SLAAC and neighbour discovery for no benefit.
  3. Encoding VLAN ID, site and function in unpredictable places. Choose one layout and apply it everywhere, including in the cloud.
  4. Forgetting the WAN and transit links. Reserve a block for infrastructure before you need it; discovering mid-deployment that your P2P addressing collides with a site block means a renumber.
  5. Not reserving. Keep at least 25% of the /48 unused at the top level so growth and acquisitions do not force a redesign.
  6. Ignoring ephemeral addressing. Cloud environments hand out addresses dynamically, and prefix delegation from the ISP can change. Where the upstream prefix is dynamic, the mechanics of requesting and handling renumbering are covered in this DHCPv6 prefix delegation guide.

Aggregation Is the Goal

Every decision above serves one goal: the rest of the network should see one route for your enterprise, or one per site. If your addresses are assigned by VLAN ID across all sites, a summarised route cannot exist and you will carry thousands of /64s. If they are assigned by site first, the site aggregate covers everything beneath it - and the day you add a VLAN, no other router needs to know.

That is the whole difference between an IPv6 plan that works for twenty years and one that needs replacing in two.

原文链接:https://www.rfc-editor.org/rfc/rfc4291.html