ARP (IPv4) and Neighbor Discovery (IPv6) were designed for trusted local networks. Any host on a segment can claim to own an address, or announce itself as the router, and its neighbours believe it. That makes the local link a place where one misbehaving or malicious machine can intercept or disrupt traffic for everyone on the segment. This article describes the attacks, the switch features that prevent them, what you can do on a Linux host or bridge when you lack managed switches, and how to detect trouble. Examples use 192.0.2.0/24 and 2001:db8:100::/64.

The attacks

• ARP spoofing (poisoning). An attacker sends unsolicited or forged ARP replies, claiming the gateway's IP address with the attacker's MAC address. Victims update their ARP caches and send traffic to the attacker, who can read it, change it, or drop it.
• Rogue DHCP server. An attacker answers DHCP requests with a gateway or DNS server of their choosing.
• Rogue router advertisements. In IPv6, any host can send an RA. Hosts accept it, configure addresses from the advertised prefix, and add the sender as a default router. A rogue RA can redirect or blackhole traffic, and it does not need malice: a laptop with internet-sharing enabled has caused many outages.
• NDP spoofing. Forged neighbour advertisements play the same role as ARP poisoning on IPv6 links. The earlier article on NDP failure modes covers the non-malicious versions of these failures.

Note that none of these cross a router. They need access to the same layer 2 segment, so the first defence is small, well-defined segments with controlled access.

Layered switch defences

Names and exact behaviour differ by vendor; the concepts are the same.

DHCP snooping is the foundation. The switch watches DHCP exchanges and builds a binding table of IP address, MAC address, VLAN, and port. Only ports you designate as trusted (uplinks, the real DHCP server) may send server replies. DAI then uses the binding table: an ARP packet whose sender IP and MAC do not match a binding is dropped. Hosts with static addresses need manual bindings or an exception, which is a common source of problems when DAI is first enabled. Roll it out in logging mode first if your switch supports that, and read the logs before enforcing.

RA Guard, described in RFC 6105, drops RAs arriving on ports where no router is expected. Its limits are known: attackers can try to evade a simple filter by using extension headers or fragmentation, and RFC 7113 discusses these issues. RFC 6980 forbids fragmenting most ND messages, which helps implementers harden against evasion. Treat RA Guard as a strong barrier against accidents and basic attacks, not an absolute defence.

Secure Neighbor Discovery (SEND, RFC 3971) uses cryptography to authenticate ND messages, but it has seen very little deployment and is not a practical choice for most networks.

Without managed switches

If your switches lack these features, move the controls to the router or bridge you do control.

On a Linux bridge, nftables in the bridge family can drop router advertisements coming from user-facing ports:

table bridge filter {
  chain forward {
    type filter hook forward priority 0; policy accept;
    iifname "port-users*" icmpv6 type nd-router-advert drop
  }
}

Adjust the interface match to your port naming, and test it by sending a deliberate RA from a lab host. Also consider filtering DHCP server messages (UDP source port 67) from untrusted ports in the same way.

On a host, particularly a server, reduce its exposure. Servers with static addressing rarely need to accept router advertisements:

sysctl -w net.ipv6.conf.eth0.accept_ra=0

Set it only where addresses and routes are configured statically, and remember that disabling it also stops SLAAC. A static neighbour entry for the gateway, such as ip neigh replace 192.0.2.1 lladdr <mac> dev eth0 nud permanent, protects a critical server against poisoning of its gateway entry, at the cost of manual maintenance when the gateway's hardware changes.

Segment design

• Use private VLANs or port isolation where hosts have no business talking to each other, such as customers sharing a switch. If clients cannot send frames to each other, they cannot poison each other.
• Put servers on small segments, ideally routed point-to-point where you control it.
• Disable unused ports, and use 802.1X where practical.
• Encrypt the traffic that matters. TLS, SSH, and VPNs mean a successful man-in-the-middle sees ciphertext. Authentication and encryption are what stop a poisoned neighbour cache from becoming a data breach.

Detection

Even with controls, watch for trouble. arpwatch records IP and MAC pairs and reports changes. For IPv6, watch for unexpected RAs:

tcpdump -n -i eth0 'icmp6 and icmp6[icmp6type] == icmp6-routeradvert'

Any RA from a source that is not your router is worth an alert. Some IDS platforms and monitoring scripts do this continuously. Also watch the neighbour tables: ip neigh showing two IP addresses mapped to the same unexpected MAC, or the gateway's MAC changing, deserves an investigation. Remember that legitimate changes occur too, such as failover between redundant gateways, so keep a record of known MAC addresses.

Responding

When you find a rogue source, locate its port from the MAC in the switch's address table, disable the port, and clear the poisoned caches on affected hosts. Then check which missing control let it happen.

Layer 2 security is mostly unglamorous configuration: trusted ports, bindings, and filters. Done once and monitored, it removes a class of intermittent failures that are otherwise very hard to diagnose.

About IPYE

IPYE (https://my.ipye.com) leases IPv4, IPv6, and ASN space; a /48 IPv6 block is free for the first year. LOA, ROA, rDNS, and WHOIS are handled by IPYE. Locations: Los Angeles, New York, Ashburn, Salt Lake City, London, Amsterdam, and Frankfurt. Questions: ipye@turnel.com.

Disclosure: I run IPYE

Monitoring a network means getting numbers off devices: interface counters, errors, temperatures, BGP session states. For decades the answer was SNMP, where a collector polls devices on a schedule. Newer devices also offer streaming telemetry, where the device pushes data to a collector. Which should a small network use? Usually the answer is "SNMP for what you have, telemetry where the equipment supports it and you have a reason". This article compares them honestly and shows minimal examples. Addresses use 192.0.2.1 for a router and 2001:db8:100::1 for its IPv6 address.

How SNMP works

An SNMP manager sends requests to an agent on the device. The agent exposes a tree of variables identified by object identifiers (OIDs) and described by MIB files. The commonly used operations are GET for a specific variable, GETNEXT or GETBULK for walking a subtree, and SET (rarely used for monitoring). Devices can also send unsolicited traps or informs on events. Interface statistics come from the IF-MIB (RFC 2863).

Three practical points:

• Versions. SNMPv1 and v2c authenticate with a community string sent in clear text, which is effectively a shared password visible to anyone who can sniff the traffic. SNMPv3 (the architecture is in RFC 3411 onward) adds user-based authentication and optional encryption. Use v3 where you can, and if you must use v2c, restrict it to the management network with an ACL and use a long random string, not public.
• 64-bit counters. The older interface counters are 32 bits and wrap quickly on fast links, producing false spikes or dips. The high-capacity counters (ifHCInOctets, ifHCOutOctets) are 64 bits. Always poll those for anything faster than a slow link.
• Polling interval. A collector sees only samples at the polling interval, so short bursts are averaged away. Polling every minute is common; more frequent polling costs the device CPU.

A v3 query looks like this, with placeholders for the credentials:

snmpget -v3 -l authPriv -u monuser -a SHA -A "<auth-pass>" \
  -x AES -X "<priv-pass>" 192.0.2.1 IF-MIB::ifHCInOctets.1

The -l authPriv flag requests both authentication and encryption. Reachability over IPv6 works the same way with a transport prefix such as udp6:[2001:db8:100::1] as the agent address. Keep SNMP's UDP port 161 closed to the internet; an open agent leaks information and can be abused for reflection.

How streaming telemetry works

In a telemetry model, the device structures its data according to a YANG model and a collector subscribes to paths in that data. The device streams updates back over a long-lived connection. A widely used interface is gNMI (gRPC Network Management Interface), usually paired with the vendor-neutral OpenConfig models, although many devices also stream models defined by the vendor. Subscriptions can be:

• Sample: send the value every N seconds.
• On change: send only when the value changes, which suits state such as an interface or BGP session going down.
• Once or poll: request a snapshot.

There are other related standards, such as NETCONF (RFC 6241) for configuration and YANG-push (RFC 8641) for subscribed notifications. The BGP Monitoring Protocol (RFC 7854) streams routing information from a router to a collector, which is a different slice of the same idea.

A subscription with the open-source gnmic client looks roughly like this; verify the flags against your version:

gnmic -a 192.0.2.1:57400 -u monuser -p "<password>" --skip-verify \
  subscribe --path "/interfaces/interface/state/counters" \
  --stream-mode sample --sample-interval 10s

The --skip-verify flag disables certificate checks and belongs only in a lab; use proper TLS verification in production.

Comparison

What a small network needs

Most small networks care about a short list:

1. Interface throughput, errors, and discards on uplinks and peering ports.
2. Device health: CPU, memory, temperature, power.
3. BGP session state and prefix counts.
4. Reachability and latency from outside (see the article on active measurement).
5. Traffic composition, from flow export (NetFlow, sFlow, IPFIX).

All of that is available from SNMP on almost any router or switch, and for Linux routers node_exporter and the routing daemon's own interfaces provide the same information. A Prometheus setup with snmp_exporter for network gear and node_exporter for servers covers a lot of ground with little effort. Telemetry earns its place when you need sub-minute resolution, event-driven alerts on state changes, or when a vendor no longer maintains SNMP support for the data you need.

Practical recommendations

• Start with SNMPv3 and 64-bit counters. It is boring and works.
• Monitor state changes with alerts, not graphs. A graph does not wake anyone; an alert on a BGP session going down does. For devices that support on-change telemetry, this is the strongest argument for it.
• Measure the monitoring itself. Alert if the collector stops receiving data, because a silent failure of monitoring looks like a quiet network.
• Protect the credentials. Keep SNMP credentials and telemetry passwords in a secret store, not in a public repository.
• Keep the management plane separate. Put polling and streaming on a management network or a restricted interface, and apply an ACL on the device.

Migration without drama

You do not have to choose one. Many networks run SNMP for baseline monitoring indefinitely and add telemetry for a small set of high-value paths, such as uplink counters and BGP state, then compare the two for a while before relying on the new one. If the numbers disagree, find out why before switching dashboards. The right measure of success is not which technology you use, but whether you find out about a problem before your customers do.

About IPYE

IPYE (https://my.ipye.com) leases IPv4, IPv6, and ASN space; a /48 IPv6 block is free for the first year. LOA, ROA, rDNS, and WHOIS are handled by IPYE. Locations: Los Angeles, New York, Ashburn, Salt Lake City, London, Amsterdam, and Frankfurt. Questions: ipye@turnel.com.

Disclosure: I run IPYE

Sometimes two servers in different racks, or different sites, need to share a layer 2 segment, for example so that virtual machines can keep their addresses when they move. The traditional answer was MPLS-based services, which needs an MPLS-capable core. VXLAN (RFC 7348) offers an alternative that needs only IP connectivity between endpoints, and EVPN (RFC 7432, with RFC 8365 for its use with VXLAN) provides a BGP-based control plane for it. This article explains the data plane, the three ways of learning where MAC addresses live, a small Linux example, and the pitfalls. Examples use 192.0.2.0/24 for the underlay and 2001:db8:100::/48 for tenant addressing.

What VXLAN does

VXLAN wraps an Ethernet frame in a UDP packet. The outer packet is ordinary IP, so the underlay needs only routing. Key facts:

• The VXLAN header is 8 bytes and carries a 24-bit VXLAN Network Identifier (VNI), which gives roughly 16 million segments, compared with 4094 usable VLAN IDs.
• The destination UDP port is 4789 (IANA-assigned). The source port is usually derived from a hash of the inner frame, which gives the underlay's ECMP something to spread on.
• The device that adds and removes the header is a VTEP (VXLAN Tunnel Endpoint).
• The encapsulation adds 50 bytes over an IPv4 underlay (outer Ethernet 14, IP 20, UDP 8, VXLAN 8) and 70 bytes over IPv6. Plan the underlay MTU so that a full-size inner frame still fits, or tenants will see the same fragmentation and black-hole problems described in the earlier MTU articles.

VXLAN does not provide encryption or authentication. Anyone who can send UDP packets to a VTEP on port 4789 can inject frames into a segment, so restrict that port to the underlay addresses of your own endpoints and never expose it to the internet.

How a VTEP finds the other end

A VTEP needs to know which remote VTEP holds a given MAC address. There are three common approaches:

Without a control plane, VTEPs learn MAC addresses the way a switch does, from received traffic ("flood and learn"). That works, but flooded traffic is replicated to many places.

A static Linux example

Two Linux hosts, 192.0.2.1 and 192.0.2.2, connected by routed IP. On the first:

ip link add vxlan100 type vxlan id 100 local 192.0.2.1 dstport 4789
bridge fdb append 00:00:00:00:00:00 dev vxlan100 dst 192.0.2.2
ip link add br100 type bridge
ip link set vxlan100 master br100
ip link set vxlan100 up
ip link set br100 up

The all-zero MAC entry in the forwarding database is the flood list: broadcast, multicast, and unknown unicast go to each dst listed, and the device learns remote MACs from received traffic. Mirror it on the second host with the local and destination addresses swapped. Attach VM interfaces or containers to br100, and give tenants addresses such as 2001:db8:100:1::/64. Check with bridge fdb show dev vxlan100 and ip -d link show vxlan100.

What EVPN adds

EVPN uses MP-BGP, with the L2VPN address family (AFI 25) and EVPN subsequent address family (SAFI 70), to carry MAC and IP information. The route types you will meet first:

• Type 2, MAC/IP advertisement: announces that a MAC (and optionally an IP) is reachable behind a VTEP.
• Type 3, inclusive multicast: announces a VTEP's interest in a VNI, building the flood list automatically.
• Type 5, IP prefix (RFC 9136): advertises an IP prefix, used for routing between segments.

Because MACs and IPs are advertised, VTEPs can answer ARP and Neighbor Discovery locally for known hosts, which reduces flooding. A MAC that moves to another VTEP is re-advertised with a sequence number so others update.

In FRR, with the Linux bridge and VXLAN interface configured as above, the control plane is enabled roughly like this:

router bgp 64496
 neighbor 192.0.2.2 remote-as 64496
 !
 address-family l2vpn evpn
  neighbor 192.0.2.2 activate
  advertise-all-vni
 exit-address-family

advertise-all-vni tells FRR to advertise every locally configured VNI. The VXLAN interface is then typically created with nolearning so that BGP, not data-plane learning, populates the table. Check FRR's EVPN documentation for the exact interface settings of your version, since the recommended Linux setup has evolved.

Underlay design

The underlay is plain routing: an IGP or eBGP carries VTEP loopbacks, and ECMP spreads the encapsulated flows across paths. Keep these in mind:

1. VTEP addresses must be reachable from each other, with a stable loopback for each VTEP.
2. MTU, as above, must be raised end to end.
3. Filter UDP 4789 at the edge of the underlay.
4. BFD or fast IGP timers help traffic move off failed links.

When not to use it

Layer 2 stretching has costs. A broadcast domain that spans sites shares its failures, loops, and noisy neighbours across all of them. If the real need is only IP reachability for a prefix at two sites, plain routing, possibly with a WireGuard tunnel, is usually easier to run. Use VXLAN and EVPN when you genuinely need the same layer 2 segment in multiple places.

Summary

VXLAN carries Ethernet frames in UDP across any routed network, identified by a 24-bit VNI. EVPN makes MAC and IP reachability a BGP matter, so you do not rely on flooding alone. Mind the 50-byte overhead, protect port 4789, and think twice before stretching layer 2 where routing would do.

About IPYE

IPYE (https://my.ipye.com) leases IPv4, IPv6, and ASN space; a /48 IPv6 block is free for the first year. LOA, ROA, rDNS, and WHOIS are handled by IPYE. Locations: Los Angeles, New York, Ashburn, Salt Lake City, London, Amsterdam, and Frankfurt. Questions: ipye@turnel.com.

Disclosure: I run IPYE

When you run a BGP session to a router in a different AS, that is eBGP. When you run one to a router in your own AS, that is iBGP. The protocol is the same, but the defaults and the rules around route propagation differ, and most of the confusing first-time failures in a multi-router network come from those differences. This article walks through them, with a minimal configuration. Examples use AS64496 as your network, AS64497 as an upstream, 2001:db8:100::/48 as your prefix, and 2001:db8:ffff::/64 for infrastructure.

What actually differs

The last row varies by vendor; in FRR the defaults are 20 for eBGP and 200 for iBGP, which makes the IGP or connected routes win over iBGP-learned ones when both exist.

The iBGP split-horizon rule

RFC 4271 says a router must not re-advertise a route learned from one iBGP peer to another iBGP peer. The reason is loop prevention: iBGP does not modify the AS_PATH, so the path attribute cannot catch a loop inside your AS. The consequence is that every iBGP speaker must hear a route directly from the router that learned it from outside, which means a full mesh of iBGP sessions. With three routers that is three sessions; the count grows as n(n-1)/2, which is why larger networks use route reflectors or confederations, covered in the next article.

Why next-hop-self matters

Suppose your edge router R1 learns 2001:db8:200::/48 from upstream AS64497 whose session address is 2001:db8:fffe::1. R1 passes the route to your internal router R2 over iBGP with the next hop still 2001:db8:fffe::1. R2 now needs a route to that address. If the upstream's link subnet is not in your IGP, R2 marks the BGP route as unreachable and will not use it. There are two common fixes:

1. Put the external link subnet into the IGP, usually as a passive interface.
2. Have R1 set itself as the next hop for iBGP advertisements with next-hop-self, so that R2 only needs to reach R1's loopback.

The second option is the one most small operators choose. It keeps external link addressing out of the IGP and means the next hop stays valid as long as R1 is reachable.

Peer between loopbacks

An iBGP session between interface addresses dies when that single interface does, even though other paths between the routers exist. Peering between loopback addresses lets the TCP session survive on any working path, provided the IGP carries the loopback routes. You need two things: the session must be sourced from the loopback (update-source), and the IGP, such as OSPF or IS-IS, must advertise both loopbacks. Static routes can serve in a very small network.

A minimal FRR configuration on R1, with R2's loopback as 2001:db8:ffff::2 and the upstream session on 2001:db8:fffe::1:

router bgp 64496
 bgp router-id 192.0.2.1
 neighbor 2001:db8:fffe::1 remote-as 64497
 neighbor 2001:db8:ffff::2 remote-as 64496
 neighbor 2001:db8:ffff::2 update-source lo
 !
 address-family ipv6 unicast
  network 2001:db8:100::/48
  neighbor 2001:db8:fffe::1 activate
  neighbor 2001:db8:fffe::1 route-map UPSTREAM-IN in
  neighbor 2001:db8:fffe::1 route-map UPSTREAM-OUT out
  neighbor 2001:db8:ffff::2 activate
  neighbor 2001:db8:ffff::2 next-hop-self
 exit-address-family

The route-map names are placeholders for real inbound and outbound policy. Recent FRR versions require such policy on eBGP sessions by default, and RFC 8212 recommends the same behaviour: an eBGP session with no explicit policy should neither accept nor send routes. Write the policy rather than turning that safeguard off.

The reverse configuration on R2 points at R1's loopback, with its own loopback as the update source.

Things that commonly go wrong

• Session stuck in Active or Connect. The loopback is not reachable through the IGP, or the update source is missing so the TCP session originates from an interface address the peer does not expect.
• Route received but not installed. The next hop is unresolvable. Check show bgp ipv6 unicast <prefix> and look for "inaccessible", then check the route to the next hop.
• eBGP to a loopback fails. With the default TTL of 1, such a session needs multihop. Prefer the link address for eBGP.
• Routes visible on R1 only. The iBGP session exists, but R2 learned the route from R1 and is not allowed to pass it on to R3. This is the split-horizon rule, not a bug.
• Exits chosen inconsistently. LOCAL_PREF is set on one router but not the other, or set after the iBGP advertisement. Set it on import at the edge, so it travels with the route.

Verifying

show bgp summary should show every session established, and external prefixes should have a sensible best path on every internal router. Confirm the next hop with show bgp ipv6 unicast 2001:db8:200::/48, and test forwarding with a traceroute from an internal router rather than assuming that a BGP table entry means a working path.

Summary

eBGP crosses AS boundaries and rewrites the path and next hop; iBGP stays inside an AS, preserves attributes, and does not re-advertise to other iBGP peers. Use loopback peering for iBGP, carry the loopbacks in an IGP, set next-hop-self at the edge, and write explicit policy on every eBGP session.

About IPYE

IPYE (https://my.ipye.com) leases IPv4, IPv6, and ASN space; a /48 IPv6 block is free for the first year. LOA, ROA, rDNS, and WHOIS are handled by IPYE. Locations: Los Angeles, New York, Ashburn, Salt Lake City, London, Amsterdam, and Frankfurt. Questions: ipye@turnel.com.

Disclosure: I run IPYE

Email is the service where IPv6 most often goes wrong, because receivers apply their strictest checks to the sending address, and IPv6 gives senders more ways to leave an incomplete record trail. A mail server that works perfectly over IPv4 can be rejected or sent to spam over IPv6 for reasons that have nothing to do with the message. This article covers what the receiving side typically verifies, the records you must publish, and how to test. Examples use 2001:db8:100::25 as the sending IPv6 address, 192.0.2.25 for IPv4, and mail.example.com.

What receivers look at

When your server connects to a receiving server over IPv6, the receiver sees only the connection's source address, the name in your EHLO, and then the message. From those it commonly checks:

• Reverse DNS. Does the source address have a PTR record, and does the PTR name resolve back to the same address? This round trip is often called forward-confirmed reverse DNS.
• SPF (RFC 7208). Is the source address authorised by the domain's SPF record?
• DKIM and DMARC. These authenticate the message and the domain, independent of the IP family.
• Reputation. Has this address, or its surrounding network, been seen sending unwanted mail?

Large mailbox providers have published sender requirements which include having IPv6 senders publish PTR records and pass authentication; check each provider's current guidelines, because they change. Without a PTR, many receivers will reject or heavily penalise IPv6 mail.

Reverse DNS for the sending address

An IPv6 PTR lives under ip6.arpa, with the 32 nibbles of the address written in reverse. For 2001:db8:100::25:

5.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR mail.example.com.

and the forward record must exist as well:

mail.example.com. IN AAAA 2001:db8:100::25
mail.example.com. IN A    192.0.2.25

Make sure the name in your EHLO (the hostname Postfix or Exim presents) is the same name, so the greeting, PTR, and forward record all agree. Each sending address needs its own PTR, since a single PTR for one address in a /64 does nothing for the others. If you send from several addresses, set the outbound source address deliberately, because the kernel's default source address selection may choose a different one from the one you published a PTR for. The reverse delegation process is covered in an earlier article.

SPF with IPv6

SPF has a separate mechanism for each family: ip4: and ip6:.

example.com. IN TXT "v=spf1 ip4:192.0.2.25 ip6:2001:db8:100::25 -all"

Points to remember:

• ip6: accepts a prefix, such as ip6:2001:db8:100::/64. Listing the whole /64 is convenient if you send from several addresses, but it also authorises every address in it, so only do that if you control the whole range.
• a and mx mechanisms look up addresses of the named hosts, and match the sender address against both A and AAAA data as appropriate to the connection's family. If your MX host has an AAAA record, it is automatically covered.
• The 10-lookup limit (RFC 7208) applies to mechanisms that cause DNS queries (include, a, mx, exists, redirect), but not to ip4 and ip6. Using literal addresses keeps you well below it.
• A missing ip6: is the typical reason mail fails SPF on IPv6 only while passing on IPv4.

What to check on the receiving side

If you accept mail on IPv6 as well, publish an AAAA record for the MX host and make sure the server listens on it. Many sites receive mail only over IPv4 by choice, which is acceptable because senders fall back to IPv4. If you do enable IPv6 inbound, test it, as an MX that answers on IPv6 but is misconfigured loses mail.

Controlling the family on the sender

Mail servers decide between IPv4 and IPv6 for outbound connections. In Postfix, inet_protocols (all, ipv4, or ipv6) sets which families the server uses, and smtp_address_preference can bias the choice where supported. Some operators send over IPv4 only while they build reputation for their IPv6 addresses, since a new address has no sending history. That is a reasonable, temporary measure: send a small volume of legitimate mail over IPv6 first, watch the responses, and increase gradually.

Reputation and the /64

IPv6 provides so many addresses that blocklists cannot list every individual one. Receivers commonly judge reputation by prefix, often a /64 or something wider. The practical consequences are that a sender sharing a /64 with a spammer can suffer for it, and that moving to a different address in the same /64 does not clear a bad record. If you run mail, ask what shared range you are in, and prefer a block where you control the whole /64.

A quick test routine

dig -x 2001:db8:100::25 +short          # PTR
dig AAAA mail.example.com +short        # does it match?
dig TXT example.com +short              # SPF includes ip6:
swaks --to test@example.org --server mx.example.org --from you@example.com

Send a test message to a mailbox you control at a large provider, and read the full headers. The Authentication-Results header shows the SPF, DKIM, and DMARC outcome and the IP address that was evaluated, so you can see the result as the receiver did, and confirm it was an IPv6 connection (the Received headers show the connecting address).

Summary checklist

Deliverability over IPv6 is mostly about completeness. Publish the full set of records, keep your sending address predictable, and introduce volume slowly.

About IPYE

IPYE (https://my.ipye.com) leases IPv4, IPv6, and ASN space; a /48 IPv6 block is free for the first year. LOA, ROA, rDNS, and WHOIS are handled by IPYE. Locations: Los Angeles, New York, Ashburn, Salt Lake City, London, Amsterdam, and Frankfurt. Questions: ipye@turnel.com.

Disclosure: I run IPYE

When you enable IPv6 on a cloud or VPS instance, the result varies far more between providers than for IPv4. One gives your VM a single /128 by DHCPv6, another a whole routed /64, a third a block of addresses carved from a shared on-link subnet, and some offer a larger routed prefix. This variation decides what you can build: a single web server is fine with one address, while containers, VMs inside the VM, VPN servers, and mail servers with several identities are not. This article explains the options and why the /64 boundary is special. Examples use 2001:db8:100::/48.

Why /64 is the unit

IPv6 subnets on ordinary links are /64 for architectural reasons, not wastefulness:

• The unicast address format in RFC 4291 assumes a 64-bit interface identifier for addresses other than those beginning with binary 000.
• SLAAC (RFC 4862) builds an address from an advertised prefix and an interface identifier, and on Ethernet-like links the identifier is 64 bits long, so the advertised prefix must be a /64.
• Neighbour discovery, privacy addresses, and stable-privacy identifiers (RFC 7217, RFC 8981) all assume that the host part is 64 bits.
• Operators, and many abuse and reputation systems, treat a /64 as roughly one customer or subscriber (the logging article discusses it).

Subnets smaller than /64 are possible with static configuration, but features that depend on the 64-bit boundary stop working, which is a reason to avoid them on links with ordinary hosts.

The common provisioning models

Read your provider's documentation to see which one you have. The two differ materially in practice: with an on-link prefix, the upstream router resolves each address with neighbour discovery, so every additional address you use on the VM must answer Neighbor Solicitations from that router. With a routed prefix, the provider forwards the whole range toward your VM's address, and you decide what is inside it.

Check what you have

ip -6 addr show scope global
ip -6 route show
ip -6 neigh show
ping -6 -c 3 fe80::1%eth0     # replace with the gateway's link-local address

If you see a /128 address and a default route via a link-local gateway, you have a single address. A /64 with an on-link route suggests an on-link model. If the provider's panel shows a "routed" prefix, expect a route towards you via your main address and no on-link route for it.

Using extra addresses on one VM

Adding addresses from an on-link /64 is simple: ip -6 addr add 2001:db8:100:1::25/64 dev eth0. Because the upstream router resolves by NDP, the kernel answers automatically. Remember to set the preferred outbound source address when it matters, since the default source selection (RFC 6724) may pick a different address from the one you configured for a service, and a mail server's source address has to match its PTR record.

With a routed prefix, add the prefix to an internal bridge or use it for containers, and let the host forward; see the Docker article for the forwarding and RA interplay.

Security groups and host firewalls

Cloud firewalls and security groups are separate for IPv4 and IPv6. Opening port 443 to 0.0.0.0/0 does not open it to ::/0, and a rule set copied from the IPv4 side without its IPv6 counterpart is the classic reason that a server answers on one family only. The opposite problem is just as real: if your host firewall is IPv4-only and the VM is globally reachable on IPv6, services you assumed to be private are exposed. Test from outside using nmap -6.

Reverse DNS and reputation

With a /128, reverse DNS is whatever the provider offers, often a single PTR in a control panel. With a routed /64 or larger you might be able to delegate ip6.arpa to your own name servers. For mail, you need a PTR for each sending address, and some providers' reputation systems classify at the /64, so a noisy neighbour in an on-link /64 can affect you. If you are in a shared /64, ask whether it is shared at all.

Avoid these mistakes

• Assuming that "IPv6 enabled" means a routed prefix.
• Choosing a provider for a service that needs several addresses, such as a VPN or a mail cluster, without checking what it routes.
• Leaving router advertisements disabled where the provider relies on them for the default route, or enabling forwarding and losing that route.
• Forgetting that DHCPv6 normally conveys no default route, which comes from the RA.
• Publishing AAAA records before testing from outside.

If your design needs more than one address, a routed /64 at minimum is what you want, and a /56 or /48 if you will have separate subnets. Ask these questions before you commit to a platform, and not when your containers cannot be reached.

About IPYE

IPYE (https://my.ipye.com) leases IPv4, IPv6, and ASN space; a /48 IPv6 block is free for the first year. LOA, ROA, rDNS, and WHOIS are handled by IPYE. Locations: Los Angeles, New York, Ashburn, Salt Lake City, London, Amsterdam, and Frankfurt. Questions: ipye@turnel.com.

Disclosure: I run IPYE

Linux IPv6 behaviour is controlled by a small set of sysctls under net.ipv6. Most defaults are sensible for a client or a simple server, but several change meaning as soon as the machine forwards packets, runs containers, or sits behind more than one uplink. This article covers the settings that most often matter on a server, explains the well-known interaction between forwarding and router advertisements, and shows how to apply and verify changes. Examples use 2001:db8::/32 and the interface name eth0. Always check the kernel documentation (ip-sysctl) for your kernel version.

Per-interface and global scopes

Most IPv6 sysctls live in net.ipv6.conf.<interface>.<name>. There are also two special groups: all and default. The default group provides the initial value for interfaces created later; all applies to existing interfaces, though how it combines with the per-interface value depends on the specific setting (for some it is a logical OR or AND, for others a plain override). When in doubt, set the value on all, default, and the specific interface, then read it back.

The settings worth knowing

The forwarding and accept_ra trap

The most common surprise is this: with accept_ra at its default of 1, the kernel accepts Router Advertisements only if forwarding is off. The moment you enable net.ipv6.conf.all.forwarding=1, for example when installing a container runtime or a VPN, the host stops processing RAs. The result is that the default route learned via RA expires and the machine loses IPv6 connectivity a short time later, often minutes after the change.

The values for accept_ra are:

• 0: do not accept RAs.
• 1: accept RAs only if forwarding is disabled.
• 2: accept RAs even if forwarding is enabled.

If a host both forwards and relies on SLAAC for its upstream route, set accept_ra = 2 on the upstream interface:

# /etc/sysctl.d/60-ipv6-server.conf
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.eth0.accept_ra = 2

If you use static addressing and a static default route instead, it is cleaner to set accept_ra = 0 and autoconf = 0 on that interface, so a rogue RA on the segment cannot change your routing.

Addresses: temporary and stable

RFC 8981 temporary addresses are valuable on clients, since they change the source address people see. On servers, you normally want a predictable source address for outbound connections, so use_tempaddr = 0 is common there. For the permanent address, addr_gen_mode = 2 selects stable-privacy generation (RFC 7217), which gives a stable but not hardware-derived identifier; mode 3 generates a random one. Both avoid embedding the MAC address as EUI-64 does. The earlier article on privacy addresses goes into the trade-offs.

If you assign a static address, check with ip -6 addr show dev eth0 that the address is not flagged tentative or dadfailed.

Redirects, source routing, and ICMP rate limiting

Servers rarely need ICMPv6 Redirects, so accept_redirects = 0 removes a way for a neighbour on the same link to influence your routing. Likewise, set accept_source_route = 0, since Routing Header type 0 was deprecated in RFC 5095. The sysctl net.ipv6.icmp.ratelimit bounds how often the kernel sends certain ICMPv6 errors. Do not lower it so far that Path MTU Discovery messages are throttled on a busy router.

Dual-stack sockets

net.ipv6.bindv6only controls whether a listening socket bound to :: also accepts IPv4 connections (as IPv4-mapped addresses). The default of 0 means one socket serves both families. Applications can override it with the IPV6_V6ONLY socket option, and some, such as nginx with ipv6only=on, do so deliberately to bind separate IPv4 and IPv6 sockets.

Neighbour table limits

The net.ipv6.neigh.default.gc_thresh1, gc_thresh2, and gc_thresh3 values set how large the neighbour cache may grow before garbage collection becomes aggressive and then entries are refused. On a host that serves a whole /64 or fronts many containers, defaults can be too small, and the failure shows up as intermittent unreachability to local addresses with neighbour table overflow in the kernel log. The article on neighbour cache exhaustion covers sizing.

Applying and verifying

sysctl -w net.ipv6.conf.eth0.accept_ra=2   # runtime change
sysctl --system                            # reload /etc/sysctl.d/*
sysctl net.ipv6.conf.eth0.accept_ra        # read back
ip -6 route show default                   # is the default route present?
ip -6 addr show dev eth0                   # is the address valid, not tentative?

Persist settings in a file under /etc/sysctl.d/, and keep that file in configuration management so a rebuilt server behaves the same. Note that settings for interfaces which appear later (a bridge, a VPN device) come from default, so set both all and default in the file. Finally, test from outside after each change, from a host that has native IPv6, and wait longer than the router lifetime in the RA before declaring a forwarding change safe, since the failure mode described above is delayed.

About IPYE

IPYE (https://my.ipye.com) leases IPv4, IPv6, and ASN space; a /48 IPv6 block is free for the first year. LOA, ROA, rDNS, and WHOIS are handled by IPYE. Locations: Los Angeles, New York, Ashburn, Salt Lake City, London, Amsterdam, and Frankfurt. Questions: ipye@turnel.com.

Disclosure: I run IPYE

"IPv6 transition" is not one technology. It is a family of mechanisms built for different positions in the network: some for a home user whose ISP has no native IPv6, some for an ISP that wants to run an IPv6-only access network, and some for a mobile carrier whose phones must still run IPv4-only apps. This article lays out the main mechanisms, what each one solves, and which ones a small operator or a server administrator is likely to meet. Examples use 2001:db8::/32 and 192.0.2.0/24.

Three families of approach

Almost every transition mechanism falls into one of three groups:

1. Dual-stack: run both protocols side by side, natively.
2. Tunnelling: carry one protocol inside the other across a network that only supports the outer one.
3. Translation: convert between IPv4 and IPv6 packets or addresses at a boundary.

The mechanisms differ mainly in which protocol the access network carries and where the state lives (on the customer device, or in a central, carrier-operated box).

Dual-stack

Dual-stack means every host and router speaks both IPv4 and IPv6, and each service is reachable over both. RFC 4213 describes it together with configured tunnelling. It is the simplest model to reason about because nothing is translated, and IPv6 traffic takes its own native path. Its drawbacks are that you still need IPv4 addresses for every host, and you operate two sets of routing, firewall rules, and monitoring. Clients choose between families using Happy Eyeballs (RFC 8305), covered in an earlier article on dual-stack hygiene.

Tunnels: 6in4, 6rd, and the obsolete ones

A 6in4 tunnel (RFC 4213) wraps an IPv6 packet in an IPv4 header, using IP protocol number 41. It is how many people reach IPv6 through a tunnel service when their ISP has none. It needs a public IPv4 address on both ends, and the encapsulation reduces the usable MTU by 20 bytes.

6rd (RFC 5969) is a variation designed for ISPs. It derives the customer's IPv6 prefix algorithmically from the customer's IPv4 address plus an ISP-owned IPv6 prefix, so a relay inside the ISP network can decapsulate without any per-customer state. The ISP delivers IPv6 over its existing IPv4-only access network, and traffic goes through the ISP's own border relay rather than a third party.

Two older approaches are mostly of historical interest. 6to4 (RFC 3056) used the anycast relay prefix and had well-known reliability problems; RFC 7526 deprecated the anycast prefix. Teredo (RFC 4380) tunnelled IPv6 over UDP through NAT and was a client-side fallback. New designs should not depend on either one.

Translation and IPv6-only access

When the access network is IPv6-only, IPv4 reachability has to come from somewhere. The main options:

• NAT64 with DNS64 (RFC 6146, RFC 6147) lets IPv6-only clients reach IPv4-only servers. A separate article in this series covers it.
• 464XLAT (RFC 6877) adds a client-side translator, the CLAT, which converts IPv4 packets from the device's applications into IPv6, and a provider-side NAT64, the PLAT, which converts them back. It solves a problem plain NAT64 cannot: applications that use IPv4 literals or IPv4-only sockets still work on an IPv6-only network.
• DS-Lite (RFC 6333) tunnels IPv4 inside IPv6 from the customer's router (the B4) to a carrier-grade NAT (the AFTR). The customer gets native IPv6 and shared, translated IPv4.
• MAP-E (RFC 7597) and MAP-T (RFC 7599) do stateless IPv4-over-IPv6 mapping, where the IPv4 address and a port range are derived from the customer's IPv6 prefix, so the carrier does not hold per-flow state. lw4o6 (RFC 7596) is a lighter variant with per-subscriber state in the provider's gateway.

Comparison

What this means for a server operator

If you run servers and not an access network, you will mostly care about two things.

First, publish IPv6 natively and keep IPv4 as well. Visitors on NAT64, 464XLAT, or DS-Lite networks reach IPv6 services directly, without translation, and that generally gives them the best path. A server with both an A and an AAAA record serves everybody.

Second, do not assume one address per user. Clients behind DS-Lite, MAP, and carrier-grade NAT share IPv4 addresses with many other users, so an IPv4 address is a poor identity for rate limiting or blocking. IPv6 clients are often easier to tell apart, though you should treat a /64 as the unit and not a single address, as discussed in the articles on IPv6 logging and neighbor tables.

You can see what a client's network is doing with a few checks:

ping -6 -c 3 2001:db8::1             # is native IPv6 working?
curl -4 https://example.com/ -I      # does IPv4 still work?
dig AAAA ipv4only.arpa +short        # RFC 7050: a NAT64 prefix appears if DNS64 is present

The special name ipv4only.arpa is defined in RFC 7050 so that hosts can discover a NAT64 prefix. It has only IPv4 records, so any AAAA answer is synthesised by a DNS64 resolver.

Choosing, in practice

• Hosting a service: dual-stack, with correct AAAA records and no filtering of ICMPv6.
• Connecting a lab without native IPv6: a 6in4 tunnel or a routed block over a VPN or BGP session.
• Running an ISP or a campus: native dual-stack first; consider IPv6-only with NAT64 or 464XLAT when IPv4 address supply becomes the constraint.
• Mobile deployments: 464XLAT is the standard answer to the "IPv4-only app on IPv6-only network" problem.

Keep your own services reachable natively over both families, and the mechanism your visitors use will not matter.

About IPYE

IPYE (https://my.ipye.com) leases IPv4, IPv6, and ASN space; a /48 IPv6 block is free for the first year. LOA, ROA, rDNS, and WHOIS are handled by IPYE. Locations: Los Angeles, New York, Ashburn, Salt Lake City, London, Amsterdam, and Frankfurt. Questions: ipye@turnel.com.

Disclosure: I run IPYE

traceroute and mtr are the first tools people reach for when something is slow or unreachable, and among the most misread. A hop with high latency or 100% loss looks like the culprit, yet often is not. This article explains how they work, how to read the output, and the IPv6 differences. Examples use 2001:db8::/32, 192.0.2.0/24 and 203.0.113.0/24, and the sample output is illustrative, not captured from a real network.

How traceroute works

Every IPv4 packet has a TTL (time to live) field, and every IPv6 packet has a Hop Limit field with the same role (RFC 8200). Each router decrements it by one, and if it reaches zero, the router discards the packet and sends back an ICMP Time Exceeded message (ICMPv4 type 11, ICMPv6 type 3). Traceroute sends probes with TTL 1, 2, 3 and so on and records who answers each. The source address of each Time Exceeded message identifies that hop. When a probe finally reaches the destination, the destination replies in the way the probe type dictates: with an ICMP Echo Reply for ICMP probes, an ICMP Port Unreachable for UDP probes to a closed port, or a TCP SYN-ACK or RST for TCP probes.

Consequences worth keeping in mind:

• Each answer comes from the router interface that received or generated the error, usually the ingress interface. You see one address per hop, not the whole device.
• The reply path is the ordinary routing path back to you, and it may differ from the forward path.
• Hops only appear if the router sends Time Exceeded. Many routers do not, or rate-limit it.

Common variants

Option names vary between implementations and versions, so check man traceroute on your system.

Reading the output

An illustrative mtr report:

$ mtr -rwbzc 100 -6 2001:db8:200::10
HOST: host1                      Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS64496  gw.example.net       0.0%   100    0.4   0.5   0.3   1.1   0.1
  2. AS64500  ???                100.0    100    0.0   0.0   0.0   0.0   0.0
  3. AS64500  core2.example.net   62.0%   100   85.1  80.2  79.0  95.3   2.4
  4. AS64501  edge1.example.org    0.0%   100   81.0  80.9  80.2  84.0   0.6
  5. AS64501  2001:db8:200::10     0.0%   100   81.2  81.0  80.4  83.9   0.5

Hop 2 shows 100% loss, and hop 3 shows 62% loss, yet hops 4 and 5 show none. The rule is simple: loss that does not continue to the final hop is not real loss. The routers in hops 2 and 3 do not forward traffic differently, they just decline to answer probes aimed at their own control plane. The destination row is what counts, and here it is clean.

Conversely, if loss starts at a hop and persists in every later hop, including the destination, that is the place to look, since traffic really is being lost at or after that point. Latency follows the same logic: a hop with high latency followed by lower latency at later hops is slow at generating ICMP, not slow at forwarding.

Why intermediate hops mislead

• Control-plane rate limiting. Time Exceeded is generated by the router's CPU, not its forwarding hardware, and routers deprioritise or rate-limit it. RFC 4443 requires ICMPv6 error rate limiting of this kind to be implemented.
• Asymmetric routing. The reply from hop N can return by a different path than the forward packets, so an unrelated return link can distort one hop's numbers. Ask for a traceroute from the other end.
• Load balancing. Routers split traffic across equal-cost paths using a hash that normally includes the addresses and ports. Classic traceroute varies the destination port per probe, so successive probes can follow different paths and the hops shown can come from several routers. Hop 5 may appear to come from router A and hop 6 from a router that is not downstream of A. Tools based on the Paris traceroute approach hold the flow fields constant to follow a single path.
• MPLS and tunnels. Hops inside an MPLS core or tunnel may be hidden or show unfamiliar addresses.
• Stars. A row of * * * means no answer within the timeout. If later hops answer, that router simply does not reply. If everything after a point is stars, either the probes or the replies are being dropped, or the path really ends there.

IPv6 specifics

• The commands differ: traceroute -6, traceroute6, mtr -6, or ping -6, depending on the system.
• IPv6 and IPv4 often take different paths to the same name, with different providers and different latency. Always test both explicitly, e.g. mtr -4 example.net and mtr -6 example.net.
• Time Exceeded for IPv6 is ICMPv6 type 3, so a firewall that blocks it will make hops disappear (see the ICMPv6 reference in this series), and Packet Too Big (type 2) is a separate message you may meet when testing large probes.
• Reverse DNS names for hops use ip6.arpa. Missing PTRs are normal and mean nothing about the path; -n skips lookups and makes the tool faster.

Practical method

1. Run it in both directions if you can, and in both IP versions.
2. Use a long run (mtr -c 100 or more); a single sample says little about loss.
3. Compare the last hop against the previous ones. If the final hop is healthy, intermediate loss is a display artefact.
4. Use a probe type that resembles your traffic (-T -p 443 for HTTPS).
5. Find the first hop where a problem begins and persists, identify its operator (-z adds AS numbers), and send them the full report with the source and destination addresses and the time of the test.

About IPYE

IPYE (https://my.ipye.com) leases IPv4, IPv6, and ASN space; a /48 IPv6 block is free for the first year. LOA, ROA, rDNS, and WHOIS are handled by IPYE. Locations: Los Angeles, New York, Ashburn, Salt Lake City, London, Amsterdam, and Frankfurt. Questions: ipye@turnel.com.

Disclosure: I run IPYE

BIRD is a widely used open-source routing daemon, common at internet exchanges and in small networks. This article builds a minimal BIRD 2 configuration for a small AS with one upstream, announcing one IPv4 and one IPv6 prefix, with import and export filters that keep you from leaking routes or accepting nonsense. A companion article in this series covers the same job in FRRouting. Examples use AS64496 (you), AS64511 (the upstream), 192.0.2.0/24 and 2001:db8:100::/48. Treat it as a template and check it against the BIRD documentation for your version.

The building blocks

A BIRD configuration is made of protocols, each of which has one or more channels per address family. A few kinds matter here:

• device: learns the interfaces and their addresses.
• kernel: exchanges routes with the operating system's forwarding table.
• static: originates routes you define by hand.
• bgp: a BGP session.

BIRD 2 handles IPv4 and IPv6 in one daemon (BIRD 1 needed separate bird and bird6 processes). A BGP session carries channels; ipv4 { ... } and ipv6 { ... } blocks inside the protocol say which families you exchange, and each channel has its own import and export filter.

A complete minimal configuration

router id 192.0.2.1;

define MY_ASN  = 64496;
define UP_ASN  = 64511;

define MY_PREFIXES_V4 = [ 192.0.2.0/24 ];
define MY_PREFIXES_V6 = [ 2001:db8:100::/48 ];

protocol device { }

# Install only BGP-learned routes into the OS forwarding table.
protocol kernel kernel4 {
  ipv4 { import none; export where source = RTS_BGP; };
}

protocol kernel kernel6 {
  ipv6 { import none; export where source = RTS_BGP; };
}

# Originate our prefixes. 'blackhole' is a placeholder: the route exists
# only so the prefix can be exported to BGP. Real traffic is delivered by
# the more-specific connected routes on your LAN interfaces.
protocol static origin4 {
  ipv4;
  route 192.0.2.0/24 blackhole;
}

protocol static origin6 {
  ipv6;
  route 2001:db8:100::/48 blackhole;
}

The export where source = RTS_BGP line keeps the static origination routes out of the operating system's table, so they cannot override or shadow your real, more-specific routes. Only originate what you own or are authorised to announce: the prefix should have a matching ROA, and the filters below must agree with it.

Filters

Import filters protect you from the upstream; export filters protect the internet from you. BIRD filters are small programs that accept or reject a route. Define one pair per family:

filter import_v6 {
  if net.len = 0 then reject;                      # no default route from BGP
  if net.len > 48 then reject;                     # too specific
  if net ~ MY_PREFIXES_V6 then reject;             # never accept our own space
  if net ~ [ ::/8+, 2001:db8::/32+, fc00::/7+, fe80::/10+, ff00::/8+ ] then reject;
  if bgp_path.len > 64 then reject;                # absurdly long path
  accept;
}

filter export_v6 {
  if net ~ MY_PREFIXES_V6 then accept;
  reject;
}

The IPv4 equivalents use net.len > 24 and a bogon set such as [ 0.0.0.0/8+, 10.0.0.0/8+, 127.0.0.0/8+, 169.254.0.0/16+, 172.16.0.0/12+, 192.168.0.0/16+, 224.0.0.0/4+ ]. The IPv6 example lists 2001:db8::/32 because it is a documentation range that should never appear in the real table. In this tutorial your own prefixes are also documentation space, so a literal copy of the filter would reject them on import (which is the desired behaviour for the real ones in your own space anyway). On a real network, substitute your actual allocation and a maintained bogon list.

The + suffix in a prefix set means "this prefix and all more specifics". The last filter in the chain is the important one: an export filter that ends in reject means a mistake elsewhere cannot cause you to export something by accident. This is the same principle of default-deny described in the BGP session checklist.

The BGP session

protocol bgp upstream1_v6 {
  description "Upstream AS64511 (IPv6)";
  local 2001:db8:ffff::2 as MY_ASN;
  neighbor 2001:db8:ffff::1 as UP_ASN;

  ipv6 {
    import filter import_v6;
    export filter export_v6;
    import limit 500000 action restart;
  };
}

protocol bgp upstream1_v4 {
  description "Upstream AS64511 (IPv4)";
  local 198.51.100.2 as MY_ASN;
  neighbor 198.51.100.1 as UP_ASN;

  ipv4 {
    import filter import_v4;
    export filter export_v4;
    import limit 1000000 action restart;
  };
}

This uses one session per address family, which is simple to reason about and to debug. BGP can also carry both families over one session, and IPv4 routes can use an IPv6 next hop with the extended next-hop capability (RFC 8950), but both ends have to agree, so follow whatever your upstream supports. The limit values above are placeholders: set them comfortably above the number of routes you actually expect, as a safety net rather than a tight cap. If the upstream sends only a default route or a partial table, the limit and the "reject default" line need to change, so adapt the filters to what you actually receive.

Check and apply

bird -p -c /etc/bird/bird.conf     # parse the config without running
birdc configure                    # reload the running daemon
birdc show protocols               # session state
birdc show route export upstream1_v6   # what we advertise
birdc show route protocol upstream1_v6 count

show protocols should show Established for both sessions. Always inspect show route export before relying on the session: it should list your prefixes and nothing else. Then verify externally from a looking glass that the prefix appears with your origin AS.

Adding RPKI validation

BIRD 2 can validate routes with RPKI using an RTR session to a validator such as Routinator or StayRTR (RFC 8210 defines the RTR protocol). You define a protocol rpki, create ROA tables, and call roa_check in the import filter to reject invalid routes. The syntax changes between versions, so take the exact form from the BIRD documentation for your release.

Operational habits

• Keep the configuration in version control, and run bird -p before every reload.
• Reload with birdc configure rather than restarting, so sessions survive.
• Review the export filter whenever you add a prefix; a missing entry is the usual reason a prefix is not announced.
• Monitor session state and route counts, as in the Prometheus article.

About IPYE

IPYE (https://my.ipye.com) leases IPv4, IPv6, and ASN space; a /48 IPv6 block is free for the first year. LOA, ROA, rDNS, and WHOIS are handled by IPYE. Locations: Los Angeles, New York, Ashburn, Salt Lake City, London, Amsterdam, and Frankfurt. Questions: ipye@turnel.com.

Disclosure: I run IPYE

A standard IPv6 subnet is a /64, which holds 2^64 addresses. That size is often described as making address scanning impractical, and for brute-force scanning of a whole subnet from one place it largely does. But the same size creates a different problem on the router that serves the subnet: it has to resolve addresses on-link with Neighbor Discovery, and a flood of packets to addresses that do not exist can fill its neighbor cache. RFC 6583 ("Operational Neighbor Discovery Problems") describes this and is the best starting point. This article explains the mechanism, what it looks like in practice, and how to reduce the risk. Examples use 2001:db8:100::/48.

How the router resolves an on-link destination

When a router receives a packet for an address inside a directly connected /64, it must find the link-layer address of the destination. It does so using Neighbor Solicitation and Neighbor Advertisement (RFC 4861):

1. The router creates a neighbor cache entry in the INCOMPLETE state.
2. It sends Neighbor Solicitation messages to the solicited-node multicast address of the target.
3. If a Neighbor Advertisement arrives, the entry becomes REACHABLE and the packet is delivered. If not, after a limited number of retransmissions, the entry is removed and the packet is dropped (the router sends ICMPv6 Destination Unreachable, code 3, "address unreachable").

Each attempted address therefore consumes a cache entry and generates multicast traffic for a short time. An attacker (or an unlucky scanner) that sends traffic to many addresses within your /64, nearly all of them unassigned, can create a very large number of INCOMPLETE entries. If the cache is a fixed size, legitimate entries may be evicted or new ones refused, and real hosts become intermittently unreachable. Some devices also exhibit high CPU use while processing the solicitations.

What it looks like

• Intermittent reachability for hosts in the subnet while the router CPU or neighbor-resolution activity is high.
• A growing neighbor table dominated by INCOMPLETE or FAILED entries.
• On Linux, kernel log messages saying the neighbor table overflowed.

On a Linux router or host:

# count entries by state
ip -6 neigh show | awk '{print $NF}' | sort | uniq -c

# show only unresolved entries
ip -6 neigh show nud incomplete

# garbage-collection thresholds
sysctl net.ipv6.neigh.default.gc_thresh1 \
       net.ipv6.neigh.default.gc_thresh2 \
       net.ipv6.neigh.default.gc_thresh3

gc_thresh3 is the hard limit on the number of entries in the table. The default values are modest, intended for ordinary hosts, and a router for large subnets may need them raised. Check your kernel's defaults rather than assuming them.

Is scanning a /64 realistic?

Trying every address in a /64 is impractical, and that is true for scanners as much as for attackers. The cache problem above does not need a complete scan; it needs only enough distinct destinations to fill the table, which is a much smaller number. And scanners do not search at random. RFC 7707 ("Network Reconnaissance in IPv6 Networks") explains that real addresses are far from random: low-numbered interface identifiers (::1, ::2, ::10), addresses embedding an IPv4 address, patterns derived from MAC addresses (EUI-64), and addresses published in DNS, logs, or certificate transparency. Those make a targeted search feasible. The takeaway is not to depend on address obscurity for security; rely on a firewall.

Mitigations

RFC 6583 discusses these in more depth; the ones most useful to a small operator are:

1. Do not give the router a huge on-link subnet if you can avoid it. Route a /64 (or a smaller allocation) to each host or customer, with a next hop that is a single known address. The router then has a route to a specific address instead of resolving a vast on-link space. For example, route 2001:db8:100:10::/64 via the server's link address, and the router resolves only that one next-hop.

2. Use /127 for point-to-point links. RFC 6164 recommends /127 prefixes on router-to-router links, which avoids a ping-pong problem and also limits the neighbor-cache impact of scanning point-to-point link prefixes. Note that this is for router links, not general subnets, where /64 remains the norm. Reserve a /64 on paper and number the link as /127.

3. Filter at the edge. Only addresses that exist should be reachable. If infrastructure links should not be reachable from the internet, don't announce or route them, or drop traffic destined to them at the border with an ACL. Where a customer has just a few hosts in a /64, a firewall that allows only those destination addresses reduces the number of resolution attempts reaching the subnet. Stateless filters should still allow ICMPv6 needed for operation.

4. Rate-limit and size the neighbor table. Many router platforms let you limit the number of entries per interface, the rate of Neighbor Solicitations, or the number of incomplete entries. On Linux, raise gc_thresh values to match the subnet and, if needed, limit unsolicited traffic with nftables.

5. Consider static or protocol-based population for critical addresses. For a small number of important hosts, a static neighbor entry (ip -6 neigh add 2001:db8:100:10::10 lladdr 02:00:00:00:00:10 dev eth1 nud permanent) removes dependence on dynamic resolution, though it creates a maintenance burden if a NIC changes.

Smaller prefixes are not a free fix

Using a /112 or another subnet longer than /64 for hosts reduces the scan surface, but it breaks features that assume a 64-bit interface identifier, notably SLAAC (RFC 4862), and is discouraged for general LAN subnets. A /64 with good filtering and routed allocations is the norm; smaller on-link prefixes are most appropriate for links between routers.

Quick checklist

• Count neighbor entries by state on your routers and watch for growth.
• Route per-host or per-customer allocations rather than exposing large on-link subnets.
• Number router-to-router links with /127.
• Filter traffic to unused addresses at the border where practical.
• Raise and monitor neighbor table limits so that legitimate hosts are not evicted.
• Never treat the size of a /64 as protection.

About IPYE

IPYE (https://my.ipye.com) leases IPv4, IPv6, and ASN space; a /48 IPv6 block is free for the first year. LOA, ROA, rDNS, and WHOIS are handled by IPYE. Locations: Los Angeles, New York, Ashburn, Salt Lake City, London, Amsterdam, and Frankfurt. Questions: ipye@turnel.com.

Disclosure: I run IPYE

A BGP session can fail quietly. The peer resets, your prefix disappears from the internet, and you learn about it from a customer rather than a dashboard. Good monitoring watches three things: whether sessions are up, whether the number of prefixes each peer sends or receives is what you expect, and whether the rest of the world still sees your routes. This article shows how to export the first two to Prometheus from an FRR router and how to alert on all three. Examples use documentation values: AS64496 (you), AS64497 (upstream), 2001:db8:ffff::1 as the peer, and 2001:db8:100::/48 as your prefix.

Choose a source of metrics

There are two common routes:

• A dedicated exporter. Community exporters exist for FRR (which reads from vtysh), BIRD, and GoBGP. They are convenient, but metric names differ between projects and versions, so look at the exporter's /metrics output and adapt the queries below accordingly.
• A small script with the node_exporter textfile collector. You control the metric names and the logic, and there is nothing extra to run. The rest of this article uses this approach.

Start node_exporter with --collector.textfile.directory=/var/lib/node_exporter/textfile. Files there ending in .prom are exposed with the host's metrics.

A textfile script for FRR

FRR can print its summary as JSON: vtysh -c 'show bgp summary json'. The top-level keys are address families such as ipv6Unicast, each containing a peers object whose entries include fields like state, pfxRcd, and pfxSnt. Field names can differ between FRR releases, so run the command once and confirm them on your version before relying on this script:

#!/bin/sh
OUT=/var/lib/node_exporter/textfile/bgp.prom
vtysh -c 'show bgp summary json' | jq -r '
  to_entries[]
  | select((.value|type)=="object" and (.value.peers != null))
  | .key as $afi
  | .value.peers | to_entries[]
  | "bgp_peer_established{afi=\"\($afi)\",peer=\"\(.key)\"} \(if .value.state=="Established" then 1 else 0 end)",
    "bgp_peer_prefixes_received{afi=\"\($afi)\",peer=\"\(.key)\"} \(.value.pfxRcd // 0)",
    "bgp_peer_prefixes_sent{afi=\"\($afi)\",peer=\"\(.key)\"} \(.value.pfxSnt // 0)"
' > "$OUT.$$" && mv "$OUT.$$" "$OUT"

Run it from cron or a systemd timer every minute. Writing to a temporary file and renaming it means Prometheus never scrapes a half-written file. The script requires jq and a user that may talk to FRR's sockets, for example a member of the frrvty group, or you can run it as root.

Alert rules

These rules use the metric names defined above plus the standard node_textfile_mtime_seconds metric that node_exporter creates for each textfile.

groups:
- name: bgp
  rules:
  - alert: BgpSessionDown
    expr: bgp_peer_established == 0
    for: 5m
    labels: {severity: page}
    annotations:
      summary: "BGP peer {{ $labels.peer }} ({{ $labels.afi }}) is not Established"

  - alert: BgpSessionFlapping
    expr: changes(bgp_peer_established[30m]) >= 4
    labels: {severity: warn}
    annotations:
      summary: "BGP peer {{ $labels.peer }} changed state several times in 30 minutes"

  - alert: BgpNoPrefixesReceived
    expr: bgp_peer_established == 1 and bgp_peer_prefixes_received == 0
    for: 10m
    labels: {severity: warn}

  - alert: BgpPrefixCountDropped
    expr: bgp_peer_prefixes_received < 0.5 * (bgp_peer_prefixes_received offset 1h)
    for: 10m
    labels: {severity: warn}

  - alert: BgpNotAdvertising
    expr: bgp_peer_established == 1 and bgp_peer_prefixes_sent == 0
    for: 10m
    labels: {severity: page}

  - alert: BgpMetricsStale
    expr: time() - node_textfile_mtime_seconds{file="bgp.prom"} > 300
    labels: {severity: warn}

Why these particular rules:

• for: 5m on the down alert avoids paging for a session that resets and recovers by itself. Note that BGP's hold timer, by default 180 seconds in FRR, delays detection of a silently dead peer unless the link goes down or you use BFD, so a session can take minutes to report as down.
• Flapping is a state-change count over a window. Combined with the router's bgp log-neighbor-changes output, it points you to the reset reason.
• Zero prefixes received while Established usually means a policy problem on one side. A sudden drop to half or less can mean the upstream changed its filters or lost its own transit.
• Zero prefixes sent while Established means your own announcements have gone: the anchor route was removed, an outbound filter changed, or the network statement stopped matching. It deserves a page because it equals an outage.
• The stale-metrics rule protects against the most embarrassing failure of monitoring: a broken script that leaves the last values in place.

The offset 1h comparison needs an hour of history and is naturally noisy for small tables, so tune the ratio to your peer. Peers with a stable table size are good candidates; a peer that sends only a default route should instead have an exact-count alert, such as bgp_peer_prefixes_received != 1.

Add an outside view

Everything above is your own router reporting about itself. If a filter at your upstream drops your prefix, your session still shows Established with prefixes sent. Complement the internal alerts with an external check that your prefix is visible:

• Query a public looking glass or a route collector API from a scheduled job and alert when your 2001:db8:100::/48 or 192.0.2.0/24 is absent, or has an unexpected origin ASN or an unexpected RPKI status.
• Consider a BGP monitoring tool such as BGPalerter, an open-source monitor that consumes public route-collector feeds and can alert on hijacks, lost visibility, and RPKI changes for the prefixes you list.

External checks are the only way to detect problems that happen beyond your edge.

Dashboards and logs

Graph bgp_peer_established, the received and sent counts, and the session uptime if you export it. Keep the router's BGP logs, especially neighbor-change and notification messages, in a central log system, because the Prometheus data tells you when something changed and the logs tell you why.

About IPYE

IPYE (https://my.ipye.com) leases IPv4, IPv6, and ASN space. A /48 of IPv6 is free for the first year, with LOA, ROA, rDNS, and WHOIS handled for you. Locations are Los Angeles, New York, Ashburn, Salt Lake City, London, Amsterdam, and Frankfurt. To get in touch: ipye@turnel.com.

Disclosure: I run IPYE

When you need your own IP addresses, there are three common ways to get them: take a block from your upstream provider (provider-assigned, PA), hold a block registered directly to you (provider-independent, PI), or lease a block from a holder who delegates it to you. The choice affects whom you depend on for routing, who can sign your RPKI records, and who can delegate your reverse DNS. This article compares them on those points only. Examples use documentation values: 2001:db8:100::/48, 192.0.2.0/24, and AS64496 (you) with AS64497 (an upstream).

A note on vocabulary: "PA" and "PI" are RIPE NCC terms, and policies differ among the five RIRs. ARIN, for instance, speaks of direct allocations and assignments versus reallocations and reassignments from an upstream. Eligibility rules change over time, so check your registry's current policy.

The three models

Provider-assigned (PA). An ISP or LIR holds a larger allocation and gives you part of it. In the registry, the provider is the holder, and your block is a sub-assignment of theirs. The block is meant to be used with that provider. If you leave, you generally renumber.

Provider-independent (PI) or direct assignment. The registry assigns the block to you, usually through a sponsoring LIR in the RIPE region or a direct agreement elsewhere. You are the registered holder, you can announce the block through any upstream, and it stays with you if you change providers. You also carry the obligations of a holder: contact data, fees to the registry or sponsor, and keeping registration accurate.

Leased. A holder grants you the right to use and announce a block for a term. In the registry, the lessor typically remains the holder, and a WHOIS object marks your use of a sub-block. When the lease ends, the block goes back. Unlike PA, it is not tied to the network you connect through: you can announce it via any upstream that will carry it, subject to the lease terms and the lessor's authorization.

Routing

All three look the same once announced; BGP does not know how you obtained a prefix. What differs is who has to cooperate.

• PA: your provider usually announces the covering aggregate, and your block is part of it. If you buy a second upstream, that second provider is asked to announce a block that belongs to someone else, which commonly requires the first provider's written authorization (a letter of authorization, LOA), proper IRR and RPKI data, and care about more-specific announcements. Many networks drop IPv4 routes longer than /24 and IPv6 routes longer than /48, so a PA block smaller than that may not propagate globally on its own.
• PI: you control the announcement. Each upstream filters customers by prefix, usually from IRR data and RPKI, and will want evidence that the block is yours. You need an ASN to originate it in your own name.
• Leased: you also need an origin ASN, which may be your own or one supplied with the lease. Upstreams typically ask for the LOA and check the same IRR and RPKI data. Confirm that the lessor will keep that authorization in place for the whole lease.

RPKI

A Route Origin Authorization (ROA) can only be created by whoever controls the resource in the RIR's portal, in other words the registered holder. That determines who can make your announcements valid:

With PA, if you later move to another provider, the old ROA names the old origin ASN. An announcement from the new ASN will then be RPKI-invalid on networks that perform origin validation (RFC 6811) until the ROA is updated. The same applies at the end of a lease: the lessor should remove the ROA, and you should not announce once it ends. For a single /48, maxLength 48 is the safest choice, because a forged more-specific announcement cannot validate against it.

Reverse DNS

Reverse DNS is delegated down the same chain as the address registration. For IPv6, delegation happens on nibble boundaries. Your 2001:db8:100::/48 corresponds to the zone 0.0.1.0.8.b.d.0.1.0.0.2.ip6.arpa. For IPv4, a /24 maps to 2.0.192.in-addr.arpa, and anything smaller needs classless delegation (RFC 2317).

• PA: the provider holds the parent zone. They either run the PTR records for you or add NS records that delegate a zone to your servers.
• PI: you hold the registration, so you add the domain object or delegation yourself through the RIR, pointing at your nameservers.
• Leased: the lessor holds the registration, and requests the delegation on your behalf, so ask about turnaround time and how changes are made before you sign.

Whichever model applies, verify the result with dig -x 2001:db8:100::25 and dig NS 0.0.1.0.8.b.d.0.1.0.0.2.ip6.arpa, and make sure each PTR name has a matching forward record.

WHOIS and IRR records

An accurate WHOIS object (inet6num or inetnum, with contacts) and a matching IRR route6 or route object are what upstreams check before accepting a prefix. Who may edit them follows the same pattern: the holder for PI, the provider for PA, and the lessor for leased space unless maintenance is delegated to you.

Questions to settle before you commit

1. Who is the registered holder, and can you see the registry object?
2. Who creates and maintains the ROA, and how fast?
3. Who handles the rDNS delegation?
4. What is the block's history? Previously used space can carry blocklist entries, so check before use.
5. What happens at the end of the term: renumbering time, ROA removal, and any notice period?

About IPYE

IPYE (https://my.ipye.com) leases IPv4, IPv6, and ASN space. A /48 IPv6 block is free for the first year. LOA, ROA, rDNS, and WHOIS are handled for you. Locations: Los Angeles, New York, Ashburn, Salt Lake City, London, Amsterdam, and Frankfurt. Questions: ipye@turnel.com.

Disclosure: I run IPYE

A BGP community is a tag attached to a route. The tag does nothing by itself; it only matters because some router, somewhere, has a policy that matches it. For a small ASN, communities are the main way to ask an upstream to do something on your behalf, and the main way to label routes inside your own network. This article covers the three community types, the well-known values worth remembering, and a modest traffic-engineering approach. Examples use the documentation ASNs from RFC 5398: our network is AS64500, upstreams are AS64501 and AS64502, and the prefix is 192.0.2.0/24.

The three kinds of community

• Standard communities (RFC 1997): a 32-bit value, conventionally written as two 16-bit halves, ASN:value. The limitation is that the first half only fits a 2-byte ASN.
• Extended communities (RFC 4360): 8 bytes with a type field. They are used mostly by VPN and flow-spec features and are rarely needed for plain internet transit.
• Large communities (RFC 8092): 12 bytes, written as three 32-bit numbers: Global Administrator:Local Data 1:Local Data 2, for example 64500:1:64501. The Global Administrator is a full 4-byte ASN, so networks with 32-bit ASNs finally have a proper namespace. RFC 8195 gives usage guidance, suggesting that the second field identifies a function and the third a parameter.

All three are optional transitive attributes. They may travel through several networks, but nothing guarantees it: a network can strip or rewrite them, and some platforms only send them to a neighbor if you explicitly enable it. If a community seems to vanish, check the send-community equivalent on your side before blaming the upstream.

Well-known communities

A handful of values have fixed meaning and are defined in RFCs. In ASN:value form they live under 65535:

NO_EXPORT is handy when you want a neighbor to use a more-specific route but not spread it further. BLACKHOLE is the standard signal for remotely triggered blackholing during an attack. It is only useful if the receiving network supports it, and operators typically expect a single host route (/32 or /128) rather than a whole block, so read their documentation first.

Communities are not authenticated

Anyone can attach any community. A network that honors communities from customers must therefore apply them only to routes the customer is allowed to originate, and RFC 7454 (BCP 194) recommends scrubbing communities that fall in your own namespace on ingress, so neighbors cannot trigger your internal policy. Do the same for yourself: on routes learned from outside, remove any 64500:*:* large communities before applying your own tags.

What a small ASN can and cannot control

Outbound traffic (what leaves you) is easy: you choose the exit with local preference. Inbound traffic (what reaches you) is decided by other networks, so you can only nudge it. The usual tools, roughly from weakest to strongest:

1. AS path prepending: make one path look longer. Weak, because many networks decide on local preference before path length, so a customer or peer route can win regardless.
2. Provider action communities: ask an upstream to set a local preference, prepend toward a given neighbor, or withhold the route from certain peers. These are defined by each upstream and published in their documentation or IRR aut-num remarks. They are often more effective than prepending because they act inside the provider's policy.
3. More-specific announcements: announce two halves of a block on different upstreams. Longest-prefix match wins, but global filters commonly drop anything longer than /24 for IPv4 or /48 for IPv6, and extra prefixes add routing-table entries for everyone.
4. MED: only compared between routes from the same neighboring AS, so it helps with two links to one upstream and not with two different upstreams.

Tagging your own routes

Define a small scheme and write it down. One workable layout using large communities, where the function is in field two (this scheme is invented for illustration; it is not a standard):

Then export policy can say "send only routes tagged 64500:2:1 to upstreams", which protects you from accidentally becoming a transit path between your two providers (a route leak).

A BIRD example

filter to_upstream_a {
  if net = 192.0.2.0/24 && (64500, 2, 1) ~ bgp_large_community then {
    # hypothetical action community published by AS64501
    bgp_large_community.add((64501, 2, 64502));
    accept;
  }
  reject;
}

filter from_upstream_a {
  bgp_large_community.delete([(64500, *, *)]);  # scrub our namespace
  bgp_large_community.add((64500, 1, 64501));
  bgp_local_pref = 200;
  accept;  # prefix, bogon, and RPKI checks omitted here
}

The (64501, 2, 64502) value only works if AS64501 actually documents it; never assume another network's scheme. Real filters should also include prefix, bogon, and RPKI validation checks.

Verify the effect

After changing a community, check from outside: use a looking glass or RIPEstat to see whether the path through the targeted upstream changed. Change one thing at a time and record it. Convergence takes minutes, and some effects appear only in networks that actually honor the community.

About IPYE

IPYE (https://my.ipye.com) leases IPv4, IPv6, and ASN space. A /48 IPv6 block is free for the first year. LOA, ROA, rDNS, and WHOIS are handled for you. Locations: Los Angeles, New York, Ashburn, Salt Lake City, London, Amsterdam, and Frankfurt. Questions: ipye@turnel.com.

Disclosure: I run IPYE

Reverse DNS (rDNS) maps an IP address back to a name. It isn't glamorous, but mail servers, logging tools, traceroute readers, and abuse desks all lean on it. IPv6 reverse DNS looks intimidating at first because of the long ip6.arpa names. The rules are simple once you see the pattern, and delegation is the same idea you already know from forward DNS.

How the name is built

IPv4 reverse names flip the four decimal octets and append in-addr.arpa. IPv6 does the same at the level of nibbles: single hex digits (4 bits). To build the reverse name of an address:

1. Write the address fully expanded, with no :: shortening and all leading zeros: 2001:0db8:abcd:0001:0000:0000:0000:0010.
2. Remove the colons: 20010db8abcd00010000000000000010 (32 hex digits).
3. Reverse the digits and put a dot between each one.
4. Append ip6.arpa.

The result for 2001:db8:abcd:1::10 is:

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

You rarely need to do this by hand. dig -x 2001:db8:abcd:1::10 does it, and so does Python:

import ipaddress
a = ipaddress.ip_address("2001:db8:abcd:1::10")
print(a.reverse_pointer)

The zone for a /48

A reverse zone covers a prefix. Each nibble of prefix length adds one label, so a /48 (12 nibbles) is a zone with 12 labels before ip6.arpa. For 2001:db8:abcd::/48:

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

The first 12 hex digits 2001 0db8 abcd, reversed. Everything below that zone name, the other 20 nibbles, is yours to define.

Who delegates what

DNS delegation is by NS records in the parent zone. For your space, the chain runs from ip6.arpa down through the RIR and, depending on how you got your space, a provider or LIR, to you:

• If you hold the space directly, you ask your RIR (or the party that manages the address-space record) to publish NS records for your reverse zone pointing at your name servers.
• If you lease or sub-allocate space, the lessor either publishes the delegation for you or maintains the PTR records on your behalf. Ask which model they support and how requests are made.

Either way you need working authoritative name servers (BIND, NSD, Knot, PowerDNS, or a hosted DNS service that supports reverse zones) before delegation is useful. Plan for at least two servers on different networks.

Delegation works on nibble boundaries

DNS zone cuts happen at label boundaries, and each label is one nibble. That means clean reverse delegation exists for prefix lengths that are multiples of 4: /32, /36, /40, /44, /48, /52, /56, /60, /64. A /47 or /53 doesn't match a single zone. It has to be split into several delegations (a /47 becomes two /48 zones). This is why I recommend subnetting on nibble boundaries from the start.

A minimal zone file

For d.c.b.a.8.b.d.0.1.0.0.2.ip6.arpa. in BIND format:

$TTL 3600
@   IN SOA ns1.example.net. hostmaster.example.net. (
        2026102601 ; serial
        3600       ; refresh
        900        ; retry
        1209600    ; expire
        3600 )     ; negative TTL
    IN NS  ns1.example.net.
    IN NS  ns2.example.net.

; 2001:db8:abcd:1::10
0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0  IN PTR web1.example.net.

Inside the zone, the owner name is the remaining 20 nibbles, reversed, without the zone suffix. The matching delegation in the parent zone is just NS records:

d.c.b.a.8.b.d.0.1.0.0.2.ip6.arpa.  IN NS  ns1.example.net.
d.c.b.a.8.b.d.0.1.0.0.2.ip6.arpa.  IN NS  ns2.example.net.

Generate PTRs from a list

Writing 20-nibble labels by hand invites typos. Generate them:

import ipaddress
zone_net = ipaddress.ip_network("2001:db8:abcd::/48")
zone_suffix = zone_net.network_address.reverse_pointer.split(".", 20)[20]
hosts = {"2001:db8:abcd:1::10": "web1.example.net.",
         "2001:db8:abcd:1::11": "mail.example.net."}
for addr, name in hosts.items():
    ptr = ipaddress.ip_address(addr).reverse_pointer
    label = ptr[: -len(zone_suffix) - 1]
    print(f"{label}  IN PTR {name}")

Keep the host list in version control and regenerate the zone, bumping the serial.

Check your work

• dig NS d.c.b.a.8.b.d.0.1.0.0.2.ip6.arpa should return your name servers.
• dig -x 2001:db8:abcd:1::10 +short should return the name.
• Query the authoritative servers directly (dig @ns1.example.net -x ...) to separate delegation problems from zone problems.
• Forward-confirm it: the PTR name should have an AAAA record pointing back to the same address (forward-confirmed reverse DNS). Mail systems and some security tools check for this.

Practical advice

• You don't need a PTR for every address. A /64 holds 2^64 of them. Publish PTRs for servers, mail relays, and anything people see in logs or traceroutes. Some operators generate generic names for dynamic pools; do that with a script rather than by hand.
• Match your naming across families. If the IPv4 PTR says mail.example.net, make the IPv6 PTR say the same and give it an AAAA.
• Mind TTLs. Short TTLs make changes quick, but values around an hour are fine for static hosts.
• DNSSEC is optional. If you sign the zone, the parent zone needs a DS record for your key.
• Delegation errors are quiet. A lame delegation (NS records pointing at a server that doesn't answer for the zone) shows up as failed lookups, so test it from the outside after any change.

About IPYE

IPYE leases IPv4, IPv6, and ASN space and sells server+IP bundles. A /48 of IPv6 is free for the year; a /44 is $20/yr and a /40 is $100/yr; an IPv4 /24 is $160/mo. LOA, ROA, rDNS, and WHOIS are handled for you. Locations: Los Angeles, New York, Ashburn, Salt Lake City, London, Amsterdam, and Frankfurt. Details: IPv6 rental, IPv4 rental, server+IP bundles. Questions: ipye@turnel.com.

Disclosure: I run IPYE

If you announce your own prefix from your own ASN, sooner or later a transit provider's route filter will ask a simple question: "does a signed record say this ASN may originate this prefix?" That record is a Route Origin Authorization, or ROA. This article covers what a ROA contains, how routers use it, and the maxLength mistakes I see most often.

What a ROA actually says

A ROA is a small signed object in the RPKI (Resource Public Key Infrastructure). It contains three things:

1. A prefix, for example 2001:db8:abcd::/48 (a documentation prefix, used here for illustration).
2. A maximum length (maxLength), the longest more-specific the origin is authorized to announce.
3. An origin ASN, for example AS64496 (also a documentation ASN).

Read it as: "AS64496 is authorized to originate 2001:db8:abcd::/48, and any more-specific of it up to the maxLength." The ROA is issued by whoever holds the address space, through their RIR's RPKI system (or their own CA). This matters when you lease space: the holder creates the ROA for your ASN, because you can't sign for space you don't hold.

How routers use it: three states

Networks that do route origin validation (ROV, RFC 6811) compare each BGP announcement to the validated ROA data and classify it:

• Valid: a ROA covers the prefix, the origin ASN matches, and the prefix length is ≤ maxLength.
• Invalid: at least one ROA covers the prefix, but either the origin ASN doesn't match or the announced prefix is longer than maxLength.
• NotFound: no ROA covers the prefix at all.

Many networks drop Invalid routes. NotFound is usually still accepted, which is why unsigned prefixes mostly work today. The practical lesson: a wrong ROA is worse than no ROA, because Invalid gets dropped while NotFound usually doesn't.

Mistake 1: maxLength set too long

The tempting configuration is a ROA for a /44 with maxLength 48, "just in case I want to split it later." RFC 9319 (BCP 185), the guidance on maxLength, recommends against this. A ROA that authorizes lots of unannounced more-specifics lets an attacker announce a more-specific with a forged origin (your ASN prepended) and still validate as Valid. Longest-prefix-match then pulls traffic to the attacker.

The conservative rule: set maxLength equal to the prefix length you actually announce. If you announce one /48, publish a /48 ROA with maxLength 48. If you announce a /44 and also four /46s, publish ROAs for exactly those, not one broad ROA.

Mistake 2: forgetting the more-specifics you announce

The opposite problem: you publish a ROA for /44, maxLength 44, then announce two /45s for traffic engineering. Both are longer than maxLength, so both are Invalid and get dropped by ROV networks, while the /44 still works. Every distinct prefix you originate needs a ROA entry that covers it at that length. Before announcing anything, write down every prefix and length you plan to originate, then check that each has a matching ROA.

Mistake 3: origin ASN mismatch

Common triggers: you changed ASNs but the ROA still lists the old one, or a provider announces on your behalf during a migration from an ASN that isn't on the ROA. A stale ROA for some other ASN doesn't hurt you as long as yours also exists, but if yours is missing, your announcement is Invalid, not NotFound. If more than one ASN legitimately originates the prefix, publish a ROA for each. Also check IPv4 and IPv6 separately: ROAs are per prefix, and it's easy to fix one family and forget the other.

Mistake 4: expecting instant effect

ROA changes don't take effect globally the moment you click save. RPKI validators fetch repository data on a schedule, then push validated payloads to routers. Allow time (often minutes, sometimes an hour or more) before blaming your config. If you're swapping ROAs, create the new one first, wait until it validates, then remove the old one.

A short verification routine

Before and after a change:

1. List the prefixes you will originate and their lengths.
2. Check the ROA set in your RIR's RPKI dashboard (or your lessor's portal) against that list.
3. Validate from the outside. Public tools such as RIPEstat's RPKI validation widget, bgp.tools, or a looking glass of a network that runs ROV show you the status as the world sees it. If you run your own validator (Routinator, rpki-client, and others), you can query it directly.
4. Confirm the route is seen at a few vantage points (a route collector like RIPE RIS or RouteViews) and the origin AS is yours.
5. Re-check after any renumbering, ASN change, or new announcement.

One more tool: AS0 ROAs

RFC 6483 defines ROAs with origin AS0, meaning "nobody is authorized to originate this prefix." Holders can use them for space they don't intend to announce, so any announcement of it is Invalid. Remember to replace one with a normal ROA before you start announcing.

ROAs vs IRR

ROAs and IRR route6 objects overlap but aren't the same: IRR data drives prefix-list generation at many providers, while RPKI drives origin validation. Publish both and keep them consistent.

About IPYE

IPYE leases IPv4, IPv6, and ASN space and sells server+IP bundles. A /48 of IPv6 is free for the year; a /44 is $20/yr and a /40 is $100/yr; an IPv4 /24 is $160/mo. LOA, ROA, rDNS, and WHOIS are handled for you. Locations: Los Angeles, New York, Ashburn, Salt Lake City, London, Amsterdam, and Frankfurt. Details: IPv6 rental, IPv4 rental, server+IP bundles. Questions: ipye@turnel.com.

Disclosure: I run IPYE

1. Get the authorization in writing

The holder of the block should give you a letter of authorization (LOA) that names your ASN and the prefix. Your upstream will usually ask for it before they accept the announcement.

2. Publish a ROA

A Route Origin Authorization tells the world that your ASN is allowed to originate the prefix. Networks that do RPKI route origin validation will otherwise treat your announcement as unknown or invalid. Make sure the max length matches what you really announce (a /48 ROA for a /48 announcement).

3. Create the route6 object

Add a route6 object in an IRR database your upstreams read, with your ASN as the origin. Many providers build their prefix filters from IRR data, so a missing object means a filtered prefix.

4. Announce the right size

Most networks accept IPv6 prefixes up to /48 and drop anything more specific. A /48 holds 65,536 /64 subnets, which is plenty for a lab or a small site.

5. Fix reverse DNS and WHOIS

Set up rDNS delegation for your blocks and make sure the WHOIS contact data points at you, not at the previous holder.

6. Verify from outside

Check the announcement from a public looking glass and confirm the ROA shows as valid. Test from two different networks before you rely on it.

If you do not have a block yet: I run IPYE (disclosure: my company). We lease IPv4 and IPv6 space that you announce from your own ASN. A /48 of IPv6 is free for the year, and we handle the LOA, ROA, rDNS and WHOIS changes described above. Details and pricing for IPv6 are at https://my.ipye.com/products/ipv6-rental and for IPv4 at https://my.ipye.com/products/ipv4-rental. Questions: ipye@turnel.com.