DEV Community: IPYE

tcpdump and Wireshark Filters for IPv6: Practical Recipes and the Extension Header Caveat

IPYE — Mon, 26 Oct 2026 19:49:31 +0000

Disclosure up front: I run IPYE, a company that leases IP space. It gets one short paragraph at the end; the rest is plain networking.

When an IPv6 problem is not obvious from logs, a packet capture usually settles it: is the Router Advertisement arriving, is the Neighbor Solicitation answered, does the handshake complete, is something sending ICMPv6 errors? The IPv6 filter syntax has a few differences from IPv4 that cause silent mistakes. This article gives recipes for tcpdump (which uses the libpcap filter language) and for Wireshark display filters, and explains the limitation that catches most people. Examples use 2001:db8:100::25, 2001:db8:100::/48, and eth0.

Two different filter languages

Both tools have filters, and they are not the same:

A capture filter (tcpdump's expression, or Wireshark's capture filter box) uses BPF syntax and decides what is recorded at all.
A display filter (Wireshark) works on dissected packets and decides what is shown from a capture.

Capture filters are efficient but crude. Display filters are expressive but need the packets to have been captured first. A typical workflow is a broad capture filter, then a display filter in Wireshark to narrow things down. Quote tcpdump expressions in the shell, because (, ), and ! have meaning there.

Basic tcpdump options

tcpdump -n -i eth0 -vv 'ip6'

-n stops name resolution, which avoids delays and extra DNS queries that pollute the capture.
-i any captures on all interfaces; it uses a different link-layer header, but ip6 filters still work.
-vv prints more detail, including hop limit.
-w file.pcap writes a capture file for Wireshark.

Addresses and prefixes

host 2001:db8:100::25
src host 2001:db8:100::25
net 2001:db8:100::/48
ip6 and not host 2001:db8:100::25

host matches either direction, net takes a prefix, and the ip6 primitive restricts the filter to IPv6.

Protocols and ports

tcp port 443, udp port 53, and icmp6 all work for IPv6. icmp6 is a shorthand for IPv6 packets with next header 58. Port filters apply to both IPv4 and IPv6 unless you add ip6 or ip, so write ip6 and tcp port 443 when you want IPv6 only.

The extension header caveat

This is the limitation that matters. In libpcap's filter language, ip6 proto 6 and similar expressions look only at the Next Header field in the fixed IPv6 header. If a packet has a Hop-by-Hop, Routing, or Fragment extension header, the next header is that extension, so a filter for TCP will not match it. Similarly, filters for ports or ICMPv6 types read at fixed offsets and assume the upper-layer header follows the 40-byte fixed header immediately. For ordinary traffic this works. For packets with extension headers it can silently miss. When a capture seems to be missing traffic you know exists, widen the filter, or capture everything for a short period and filter in Wireshark, whose dissector follows the extension header chain.

There is also a primitive for chains: ip6 protochain 44 matches packets that have a Fragment header anywhere in the chain.

ICMPv6 and neighbor discovery

The ICMPv6 type is the first byte after the 40-byte header, so with the no-extension-header assumption you can match it at offset 40:

Goal	Filter
Router Solicitation (type 133)	`icmp6 and ip6[40] == 133`
Router Advertisement (134)	`icmp6 and ip6[40] == 134`
Neighbor Solicitation (135)	`icmp6 and ip6[40] == 135`
Neighbor Advertisement (136)	`icmp6 and ip6[40] == 136`
All neighbor discovery (133 to 136)	`icmp6 and ip6[40] >= 133 and ip6[40] <= 136`
Packet Too Big (type 2)	`icmp6 and ip6[40] == 2`
Echo request and reply (128, 129)	`icmp6 and (ip6[40] == 128 or ip6[40] == 129)`

Neighbor discovery messages must be sent with a hop limit of 255, and receivers reject anything else, which stops off-link senders from spoofing them. The hop limit is the byte at offset 7, so icmp6 and ip6[7] == 255 and ip6[40] >= 133 and ip6[40] <= 136 shows only well-formed discovery packets, and a capture with ip6[7] != 255 on the same types shows suspicious ones. For multicast, ip6 multicast matches any IPv6 multicast destination.

Useful checks with these:

Is SLAAC working? Capture type 134 on a client interface. If none arrive, the problem is upstream of the host: router, switch, or MLD snooping.
Is a neighbour answering? Capture types 135 and 136 for the target address and look for the advertisement.
Path MTU trouble? Capture type 2 to see whether Packet Too Big reaches the sender. Absence in the face of black-holed large packets suggests filtering, as described in the earlier MTU and ICMPv6 articles.

TCP handshake and flags

For a SYN on IPv6 without extension headers, the TCP flags byte is at offset 53 (40 plus 13 in the TCP header):

ip6 and tcp and (ip6[53] & 0x02 != 0)

Behaviour of protocol-relative expressions such as tcp[13] with IPv6 has varied between libpcap versions, so the explicit offset is more predictable, and you should verify any filter against known traffic first.

Fragments

ip6 protochain 44 matches fragmented packets. IPv6 fragmentation is done only by the source, so fragments you see came from the endpoint or from a tunnel entry point, and a flow of fragments often points to an MTU problem.

Wireshark display filters

Display filters use field names:

ipv6.addr == 2001:db8:100::25, ipv6.src, and ipv6.dst for addresses.
icmpv6 for all ICMPv6, and icmpv6.type == 135 for a specific type.
ipv6.hlim == 255 or ipv6.hlim < 64 for hop limit.
ipv6.nxt == 44 for packets whose fixed header points to a fragment header.
tcp.flags.syn == 1 && tcp.flags.ack == 0 for new connections, regardless of address family.
ipv6 && !icmpv6 to remove ICMPv6 noise while looking at application traffic.

Summary

Use capture filters to limit what you record and display filters to explore it. Remember that libpcap IPv6 offsets assume no extension headers, check the hop limit of 255 for neighbor discovery, and test a new filter against traffic you know exists before trusting an empty result.

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

IXP Basics for Small Networks: Route Servers, Peering Policies, and PeeringDB

IPYE — Mon, 26 Oct 2026 19:46:16 +0000

Disclosure up front: I run IPYE, a company that leases IP space. It gets one short paragraph at the end; the rest is plain networking.

An Internet Exchange Point (IXP) is a shared layer 2 network where many networks connect so they can exchange traffic directly instead of through a transit provider. For a small network the attraction is shorter paths and less transit traffic; the price is operational care, because a mistake on a shared LAN affects other members. This article explains how an exchange works, the difference between bilateral peering and route servers, what PeeringDB is for, and the safety habits that make you a good neighbour. Examples use AS64496 as you, AS64497 as a peer, and 2001:db8:ffff::/64 standing in for an IXP peering LAN.

How an IXP works

Members connect a port from their router to the exchange's switching fabric and receive an address from the IXP's peering LAN, in both IPv4 and IPv6. They then run eBGP sessions with each other across the fabric. The exchange only forwards Ethernet frames; it does not route, and it does not see your BGP sessions as anything but traffic. Exchanges publish member rules, which commonly include:

One MAC address per port, and no proxy ARP or similar tricks.
Only IPv4, ARP, and IPv6 frames on the peering LAN, with no discovery protocols that leak onto the fabric, such as spanning tree or vendor neighbour-discovery protocols.
Do not announce the peering LAN prefix into global BGP, and do not point a default route at another member.

The last rule matters: a default route toward a peer uses that peer's network as transit without asking. Send across an IXP only traffic for prefixes the peer announced to you.

Bilateral sessions and route servers

There are two ways to learn routes at an exchange.

Approach	How it works	Strengths	Limits
Bilateral	You configure a separate eBGP session with each peer	Full control of policy and per-peer limits	One agreement and one session per peer
Route server	You peer with the IXP's route server, which redistributes members' routes	One or two sessions give many peers	You accept what members announce, filtered by the server

A route server (RFC 7947) is a BGP speaker that passes routes between members without adding its own AS number to the AS_PATH, and without changing the next hop, so traffic still flows directly between the members. Route servers are an efficient way for a small network to reach many peers quickly. Many networks use both: route servers for the long tail and bilateral sessions with the largest partners.

Peering policies and PeeringDB

Every network chooses whom it will peer with. Policies are often summarised as open, selective, or restrictive, which are the values the PeeringDB policy field uses. Open means the network will usually agree to peer with anyone who asks. Selective means it applies conditions, such as a minimum traffic level or a presence in specific locations. Restrictive means peering only in particular circumstances.

PeeringDB is a community-maintained database where networks, exchanges, and facilities publish their details. A network record typically includes its ASN, the AS-SET used for filtering, expected prefix counts for IPv4 and IPv6, its policy, contact addresses, and the exchanges where it has ports. Use it two ways:

As a requester: look up a prospective peer, read its policy, and send a short message to its listed peering contact with your ASN, the exchange, and the traffic you expect.
As an operator: keep your own record accurate. Many networks build filters and maximum-prefix limits from the listed AS-SET and prefix counts, and many refuse to peer with networks that have no usable record.

Treat the data as a starting point and check it against the IRR and RPKI.

What to configure on each session

The baseline filters for any peer, whether bilateral or via a route server, follow RFC 7454:

Prefix filters: accept only the prefixes the peer is entitled to announce, built from its AS-SET, or rely on the route server's filtering and still apply your own checks.
No bogons: reject private, documentation, and reserved address space and ASNs.
RPKI: reject routes that validate as invalid.
Maximum prefixes: set a limit from the peer's expected count, with a margin, so a leak ends the session instead of filling your table.
Next hop check: accept routes from a peer only if the next hop is that peer's address on the exchange, unless you are using a route server.
First AS check: for a bilateral session, require the peer's own ASN to be first in the AS_PATH. Do not enable it on route server sessions, since the route server does not insert its own ASN.
Outbound: announce only your own prefixes and your customers' prefixes, never routes learned from other peers or transit, or you turn yourself into a free transit path.

A sketch in FRR for a bilateral IPv6 peer:

router bgp 64496
 neighbor 2001:db8:ffff::2 remote-as 64497
 neighbor 2001:db8:ffff::2 description AS64497 at IXP
 !
 address-family ipv6 unicast
  neighbor 2001:db8:ffff::2 activate
  neighbor 2001:db8:ffff::2 maximum-prefix 100
  neighbor 2001:db8:ffff::2 prefix-list PEER-AS64497-IN in
  neighbor 2001:db8:ffff::2 route-map PEER-OUT out
 exit-address-family

The names and the limit of 100 are placeholders. Your prefix-list and route-map must still be written, as discussed in the earlier customer filtering and communities articles.

Local preference and traffic engineering

Operators commonly give peer routes a higher local preference than transit routes, which is a policy choice, not a protocol rule. Tag routes with communities on receipt, so you can recognise their origin and avoid re-exporting them.

Is it worth it?

An exchange port has a cost, and you need a presence or a remote connection. Before joining, use flow data, as described in the NetFlow article, to estimate how much of your traffic goes to networks present there.

Summary

An IXP is a shared Ethernet fabric over which you run BGP with other members. Use route servers for breadth and bilateral sessions where you need control, keep your PeeringDB record accurate, apply the baseline filters to every session, and announce only what you are entitled to announce.

About IPYE

Disclosure: I run IPYE

NetFlow, sFlow, and IPFIX for a Small ISP: Choosing a Flow Export and Reading It

IPYE — Mon, 26 Oct 2026 19:43:25 +0000

Disclosure up front: I run IPYE, a company that leases IP space. It gets one short paragraph at the end; the rest is plain networking.

Interface counters tell you how much traffic crossed a link. They do not tell you which prefix, port, or customer produced it. Flow telemetry fills that gap: the router, switch, or a Linux host summarises traffic as flows and exports records to a collector. For a small ISP or hosting network it answers the practical questions of who is using the bandwidth, what an attack looked like, and where capacity is going. This article compares the main formats, shows a small Linux setup, and covers IPv6-specific points. Examples use 2001:db8:100::/48 and 203.0.113.0/24.

What a flow is

A flow is a set of packets sharing key fields, typically the source and destination address, protocol, and source and destination ports, observed within a time window. The exporter keeps a cache of active flows and sends a record when a flow ends or after a timeout. Each record holds the key fields plus counters for packets and bytes, timestamps, interfaces, and often TCP flags, AS numbers, and next hop. This is metadata; there is no payload.

The formats

Format	Model	Notes
NetFlow v5	Fixed-format records	IPv4 only, so it cannot describe IPv6 traffic
NetFlow v9 (RFC 3954)	Template-based records	Supports IPv6 and flexible fields
IPFIX (RFC 7011)	Template-based, IETF standard, derived from NetFlow v9	Registered fields; the vendor-neutral choice
sFlow	Samples packets and interface counters	Does not keep a flow cache; the collector builds flows from samples

The IPv6 point matters: if your exporter only speaks NetFlow v5, IPv6 traffic will be missing from your picture. Use v9, IPFIX, or sFlow. Template-based formats first send a template that describes the record layout, followed by data records, so collectors must receive the templates; a collector restarted mid-stream may discard records until the next template arrives.

By convention NetFlow is often sent to UDP port 2055, though this is not a standard for NetFlow. IANA registers port 4739 for IPFIX and 6343 for sFlow.

Sampling and what it costs

Exporting every flow is expensive on busy links, so most devices sample, examining one packet in N. The collector then multiplies byte and packet counts by the sampling rate to estimate totals. Consequences:

Large flows are estimated well. Small and short flows may be missed completely.
A sampled record is evidence that traffic existed, not an exact count.
Mixing devices with different sampling rates without recording the rate gives wrong totals.

Record the sampling rate in your documentation and make sure your collector uses it. sFlow is built around this idea, since its samples are packet headers taken at a defined rate, while NetFlow and IPFIX exporters can run either sampled or unsampled, depending on the hardware.

A small Linux setup

On a Linux router without hardware flow export, a software exporter can read traffic from an interface. One option is softflowd, which can export NetFlow v9 or IPFIX, and another is pmacctd. For sFlow on a host, hsflowd is common. A collector can be nfdump with nfcapd, or pmacct's nfacctd.

A sketch with softflowd and nfdump:

softflowd -i eth0 -n 127.0.0.1:2055 -v 9
nfcapd -l /var/cache/nfdump -p 2055 -D
nfdump -R /var/cache/nfdump -s srcip/bytes -n 10

The first command exports flows from eth0 as NetFlow v9; the second receives and stores them; the third prints the top ten source addresses by bytes. Add a filter for the IPv6 family using the syntax your nfdump version documents. Option names differ between tools and versions, so check the manual pages. Keep the collector on a separate machine or at least a separate volume for any real network, because flow storage grows steadily.

IPv6 considerations

Aggregate by /64. As in the logging article, one subscriber can use many addresses within a /64. Ranking individual IPv6 addresses by bytes will mislead you, so most tools let you group by prefix length. Use /64, and widen to /48 for delegations.
Extension headers. Some exporters classify packets with extension headers poorly, so ports may be zero.
Dual-stack views. Report IPv4 and IPv6 separately before combining them.
Fragments. Non-first fragments have no port information, so they appear as port zero or in separate flows.

Useful questions to ask the data

Top talkers: which destination prefixes or customers use the most bytes in the last hour.
Attack triage: packets per second by destination address and protocol, to see whether a spike is a flood aimed at one host.
Capacity planning: daily peaks by upstream, peer, or customer.
Peering decisions: which origin ASes carry the most traffic, if your records include AS numbers, to judge whether a direct peering would be worthwhile.
Abuse and complaints: whether a host did contact a destination at a stated time, with timestamps that you should verify against NTP-synced clocks.

Operational notes

Make sure router and collector clocks are synchronised. Choose flow timeouts deliberately, since active timeouts break long flows into several records and short inactive timeouts split idle connections. Flow records are personal data in some jurisdictions, so set retention, and restrict access. Finally, protect the collector: it receives unauthenticated UDP, so accept exports only from known router addresses.

Summary

Use NetFlow v9, IPFIX, or sFlow, because NetFlow v5 cannot carry IPv6. Know your sampling rate and apply it, aggregate IPv6 by /64, keep clocks and timeouts sane, and treat flow data as an estimate that answers "who and how much" rather than an exact bill of every packet.

About IPYE

Disclosure: I run IPYE

Rate Limiting and Banning IPv6 Clients by /64 with nftables

IPYE — Mon, 26 Oct 2026 19:00:52 +0000

Disclosure up front: I run IPYE, a company that leases IP space. It gets one short paragraph at the end; the rest is plain networking.

Rate limits and ban lists assume that an address stands for a client. In IPv4 that is a decent approximation. In IPv6 it fails: a single customer with a /64 has 2^64 addresses available, and a script that picks a fresh source address for every request will sail past any per-address limit and fill your ban list with entries that never match again. The fix is to aggregate: limit and ban on a prefix, usually the /64. This article shows how to do that with nftables and what to watch out for with fail2ban. Examples use 2001:db8:100::/48 and 203.0.113.0/24; test every rule on a non-production machine, and check syntax against your nftables version.

Choosing the unit

The reasoning is covered in the article on IPv6 logging and abuse handling: a /64 is a normal subnet, and the host inside it can use any address in it. So the default unit for IPv6 limits is the /64. For IPv4 the equivalent is the single address (or a /32), which is a poor stand-in for a person behind carrier-grade NAT, but that is a separate issue.

Some cautions apply before you start:

A /64 can be shared between many users on some networks, such as public Wi-Fi or mobile networks. A strict limit on a shared /64 hurts innocent users. Use limits that suit your service, and treat bans as temporary.
Some customers receive more than a /64 (a /56 or /48), so a determined client can hop between /64s. Widen the unit when evidence supports it.

Per-/64 rate limiting with a meter

nftables can limit using a dynamic set keyed on a masked address. The following limits new TCP connections to port 443, counting all addresses within the same /64 together:

table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;

    ct state established,related accept
    iif lo accept
    meta l4proto ipv6-icmp accept

    tcp dport 443 ct state new \
      meter flood6 { ip6 saddr & ffff:ffff:ffff:ffff:: \
                     timeout 5m limit rate over 20/second burst 40 packets } \
      counter drop

    tcp dport 443 accept
  }
}

Here ip6 saddr & ffff:ffff:ffff:ffff:: masks the source address to its top 64 bits, so every address in the /64 maps to the same meter entry. The limit rate over clause matches packets above the rate, and these are dropped. The timeout removes idle entries so the meter does not grow without bound. Meter syntax has changed between nftables releases, so check nft -c -f file.nft for validity and the wiki for your version. Add an equivalent rule for IPv4 with ip saddr, whose natural unit is the single address.

Keep ICMPv6 accepted ahead of any rate rule, as the earlier article on ICMPv6 explains: dropping neighbour discovery or Packet Too Big messages causes outages that look like unrelated problems. Rate-limit ICMPv6 separately and generously if you need to, instead of blocking it.

A ban list of prefixes

For persistent offenders, keep a set of prefixes. An interval set holds ranges, and timeout lets entries expire:

table inet filter {
  set banned6 {
    type ipv6_addr
    flags interval, timeout
  }
  chain input {
    type filter hook input priority -10; policy accept;
    ip6 saddr @banned6 drop
  }
}

Add and remove entries at runtime:

nft add element inet filter banned6 { 2001:db8:100:1::/64 timeout 1h }
nft delete element inet filter banned6 { 2001:db8:100:1::/64 }
nft list set inet filter banned6

An entry is one prefix, regardless of how many addresses inside it were used, so the list stays small. Always set a timeout: prefixes get reassigned, and a permanent ban can end up blocking an unrelated user months later. Review hits with a counter on the rule.

fail2ban and IPv6

fail2ban watches logs and bans the addresses it sees. Current versions support IPv6, and ban actions exist for nftables. Two points need attention:

It bans individual addresses by default. An attacker rotating inside a /64 will not be stopped by a ban on one address. Options are to use an action that adds the whole /64 to a prefix set, which means a custom action or filter configuration, or to make rate limiting by /64 in nftables your primary defence and use fail2ban for slower, credential-based abuse such as SSH.
Matching log lines. The filter must capture IPv6 addresses in the format your service logs. Make sure normalisation and the form of the address are what the regex expects. Test with fail2ban-regex against real log lines containing IPv6 addresses.

Remember ignoreip: put your own management addresses and prefixes in the ignore list, including IPv6 ones, so a typo does not lock you out.

Application-level limits

Reverse proxies and web servers have their own limits, keyed by whatever variable you choose. By default, nginx's limit_req_zone keys on the client address, and this is the per-address problem again. Where the proxy cannot aggregate easily, apply the limit in the firewall in front of it. If the proxy sits behind a load balancer, use the real client address, as the article on the PROXY protocol explains, or all limits would apply to the balancer.

Testing

nft -c -f /etc/nftables.conf     # check syntax without applying
nft list meter inet filter flood6   # inspect the entries (name may differ by version)

Generate traffic from several source addresses in a test /64 and confirm they share a counter, and that traffic from a different /64 does not. Then check that a normal client, with a few connections, is never limited.

Summary

Aggregate on the /64, expire every ban, keep ICMPv6 flowing, and test from a real IPv6 host. A limit that counts addresses in IPv6 is a limit that attackers can ignore with no effort.

About IPYE

Disclosure: I run IPYE

IPv6 Logging and Abuse Handling: Why the /64 Is the Unit

IPYE — Mon, 26 Oct 2026 19:00:22 +0000

Disclosure up front: I run IPYE, a company that leases IP space. It gets one short paragraph at the end; the rest is plain networking.

In IPv4, one address usually identifies one customer or one host, so counting, blocking, and reporting by address works well enough. In IPv6 that stops being true. A single subscriber can have a /64 or larger, and a host with privacy addresses (RFC 8981) changes its source address regularly. A log that treats each IPv6 address as a separate client counts one machine as thousands, misses abuse patterns, and fills with entries that never repeat. This article covers what to log, how to aggregate, how to find the right contact, and what to put in an abuse report. Examples use 2001:db8:100::/48 and 203.0.113.0/24.

Log the full address, aggregate for analysis

Keep the complete address in the raw log, since you may need it later. Then derive an aggregate for analysis. Useful reasoning units are:

Observation	Block or count by
One misbehaving client, stable address	The single address, only if it stays fixed
Client rotating within its subnet	The /64
Client rotating across several /64s	The /56 or /48 of the delegation
Whole network misbehaving	The announced prefix or ASN, after checking it

The reason for the /64 is that it is the standard size of a subnet, and a device on that subnet can pick any address in it, so no one address is meaningful. Home networks and mobile networks differ in what they delegate, and you cannot see this from the outside, so be ready to widen the unit when evidence shows an attacker moving between /64s.

Normalise the text

IPv6 allows many textual forms of the same address: leading zeros, :: compression, and upper or lower case. RFC 5952 defines a canonical form (lowercase, leading zeros removed, longest run of zeros compressed). If you search logs with grep, differently formatted values will not match each other. Normalise addresses at ingestion, or store them in a type that understands them. In PostgreSQL, for instance, the inet type stores addresses numerically, and you can group by /64 with a query like:

SELECT network(set_masklen(client_ip, 64)) AS subnet, count(*)
FROM access_log
WHERE family(client_ip) = 6
GROUP BY 1
ORDER BY 2 DESC
LIMIT 20;

In scripting, Python's ipaddress module can do the same: ipaddress.ip_network('2001:db8:100:1::25/64', strict=False) returns the enclosing /64.

Take care with proxies and NAT

Behind a load balancer, the logged address may be the balancer's. Restore the real client address first, using the PROXY protocol or a trusted header, as discussed in an earlier article, or your records will say nothing about the client. IPv4 clients behind carrier-grade NAT share one address among many users, so IPv4 evidence is weaker than it looks. IPv6 evidence, though better, is also not a person.

Time and records

Record time in UTC with its zone, and record the time zone of any report you send. For abuse, an address without a timestamp cannot be traced, because a prefix may be reassigned and a subscriber's address may rotate. Keep what you need, for as long as you need it, and no more. IP addresses are treated as personal data in some jurisdictions, so follow your own retention policy and applicable law, and decide in advance who may query these logs.

Find the right contact

To report abuse you need the responsible network's contact. Look up the address with RDAP or WHOIS:

whois 2001:db8:100:1::25

Read the most specific record that covers the address, not the parent allocation: a sub-delegation to a customer or hosting service often has its own contact. Look for the abuse-c or abuse mailbox, the organisation, and the inet6num range. If the specific record has no abuse contact, go up a level. The routing registry or origin AS data show who announces the prefix, which can lead to the upstream when the registered organisation does not respond. The article on WHOIS and RDAP describes reading these records.

What a useful abuse report contains

The offending address and the prefix (the /64) it came from.
Timestamps in UTC, with the time zone stated.
A short, factual description of the behaviour, such as repeated login attempts or scraping against a specific service.
A few sample log lines, with your own sensitive data removed.
Whether the traffic is ongoing.
Your contact details, and what action you ask for.

Keep it brief and factual, one incident per report, and sent to the registered contact. Do not attach large log files unless requested.

Blocking responsibly

Start narrow: block the /64, not the /48, unless evidence supports widening.
Use expiry on every block, so mistakes and reassigned prefixes age out.
Check what you are blocking: a /64 in a hosting network might be a shared service, and a mobile network /64 may be shared between users, depending on how the operator assigns them.
Do not block ICMPv6 as a side effect of blocking addresses.
Record why each block was added.

Summary

Treat the /64 as the basic unit, log in canonical form, keep the full address, aggregate for analysis, and send precise reports to the contact in the most specific registry record. Done consistently, IPv6 abuse handling works much like IPv4, with the unit of identity changed.

About IPYE

Disclosure: I run IPYE

GeoIP and Geofeeds: Getting an IPv6 Prefix Located Correctly

IPYE — Mon, 26 Oct 2026 18:53:59 +0000

Disclosure up front: I run IPYE, a company that leases IP space. It gets one short paragraph at the end; the rest is plain networking.

Anyone who has had a new address block mislocated knows the symptoms: a website shows content in the wrong language, a streaming service refuses access, or a fraud check flags a user because the address "is in" another country. IP geolocation is not a property of the network; it is an inference made by commercial and open datasets from many signals. Because they are inferences, they can lag behind changes and be plain wrong, especially for new prefixes, moved prefixes, and IPv6, where address space is large and measurement signals are sparse. This article explains where location data comes from, what a geofeed (RFC 8805) is, and how to maintain accurate data. Examples use 2001:db8:100::/48 and 192.0.2.0/24.

Where location data comes from

Geolocation providers combine several kinds of evidence:

Registry data: the country in the allocation or assignment record in WHOIS or RDAP. It is coarse and reflects where the holder registered the block, not where traffic originates.
Network measurements: latency from probes in known places, and traceroute paths with location hints in router names.
Routing data: which AS announces the prefix, and where that AS operates.
Customer-submitted corrections: the data providers accept from address holders and users.
Self-published geofeeds: the topic of this article.

None of these is authoritative, which is why two providers can disagree about the same address, and why a block that moved from one country to another can keep its old location for a long time.

What a geofeed is

A geofeed is a plain CSV file, published by the party that knows where its address space is used, listing prefixes and their locations. RFC 8805 defines the format: one line per prefix, with these fields:

Field	Meaning	Example
`ip_prefix`	An IPv4 or IPv6 prefix	`2001:db8:100::/48`
`alpha2code`	ISO 3166-1 country code	`US`
`region`	ISO 3166-2 subdivision code	`US-CA`
`city`	Free-text city name	`Los Angeles`
`postal_code`	Postal code	usually left empty

Lines starting with # are comments, and the file is UTF-8 text. A complete example:

# Geofeed for AS64496
192.0.2.0/24,US,US-CA,Los Angeles,
2001:db8:100::/48,US,US-CA,Los Angeles,
2001:db8:101::/48,US,US-NY,New York,

The RFC discourages postal codes because of privacy concerns, and recommends not publishing location data more precise than needed. A prefix can be given a country only, or country and region, by leaving later fields empty. Geofeed data is a statement by the publisher, meant to be consumed by providers who choose how much to trust it.

Making a geofeed discoverable

A file nobody finds does nothing. RFC 8805 describes publishing its URL in the address registration record, and RFC 9632 specifies finding and using it in more detail, including a geofeed: attribute for RPSL-based registries, with the older practice of a remarks: line also in use. The URL must be served over HTTPS. The mechanism available differs among the five RIRs, so read your registry's documentation on where the URL can be recorded. RFC 9632 also describes how the file can optionally be authenticated using RPKI, which helps consumers verify that it was published by the holder of the space.

An RPSL-style record for a registry that supports the attribute might look like this:

inet6num: 2001:db8:100::/48
geofeed:  https://example.com/geofeed.csv

Check your registry's schema, as this varies.

Maintaining it

Keep it in sync with reality. When you move or lease out a prefix, update the file. A stale line is worse than none.
Match the announced prefixes. Entries can cover more specific prefixes than you announce, but a feed that does not correspond to the BGP table is harder for consumers to trust.
Serve it reliably. Use HTTPS, and a stable URL, and keep it available. Consumers fetch it periodically.
Validate the syntax before publishing: well-formed CIDR, correct country codes, no stray whitespace, valid UTF-8.

Correcting a provider's data

A geofeed is a hint, and providers pick it up at their own pace. For a prefix that is still wrong:

Look it up at several providers' public lookup pages, and note which are wrong.
Make sure your registry record and geofeed are correct and consistent.
Use each provider's correction process, which typically accepts a prefix and the intended location, sometimes with a link to the geofeed.
Recheck after a while. Corrections take time to propagate into the databases that applications download.

IPv6 specifics

Geolocation databases often handle IPv6 at larger granularity, so announcing and registering a prefix as a single /48 with one location gives the cleanest result. If you split one /48 between cities, providers have little to go on below the /48, and a /64-level split is rarely honoured. Users on IPv6 also move through privacy addresses and dynamic prefixes, so data about a whole site's prefix generalises better than about single addresses. Plan your address layout so that each location gets its own prefix of a size providers can use, as discussed in the subnetting articles.

What not to rely on

Do not use IP geolocation for anything that must be correct, such as legal decisions, or treat it as proof of a user's location. It is a statistical aid. For a new block, publish the geofeed before the block carries traffic, correct what is wrong early, and keep it current.

About IPYE

Disclosure: I run IPYE

BFD Basics: Fast Failure Detection for BGP and Static Routes

IPYE — Mon, 26 Oct 2026 18:53:05 +0000

Disclosure up front: I run IPYE, a company that leases IP space. It gets one short paragraph at the end; the rest is plain networking.

When a link fails cleanly, the interface goes down and routing reacts at once. Many failures are not clean: a switch or media converter in the middle keeps the link light on while packets stop flowing, a line card stops forwarding without dropping the interface, or a remote process hangs. In those cases the router learns of the problem only when a protocol timer runs out. BGP's default hold time is commonly 90 or 180 seconds, depending on the implementation, which is a long time to send traffic into a black hole. Bidirectional Forwarding Detection (BFD) exists to shrink that to a fraction of a second or a few seconds. This article explains how BFD works, how to configure it, and when it causes more harm than good. Examples use AS64496, AS64511, and 2001:db8:ffff::/64.

What BFD is

BFD (RFC 5880) is a lightweight hello protocol, independent of any routing protocol. Two systems exchange small control packets at a negotiated rate over a path. If a system stops receiving them for a set time, it declares the path down and tells the routing protocols that registered an interest. BGP, OSPF, IS-IS, and static routes can all use it, so one fast detector can serve many protocols.

Two things make it effective. The packets are tiny and simple, so implementations can run them frequently, sometimes in a router's forwarding hardware instead of its control CPU. And BFD tests the forwarding path between the two systems, not just the routing process, which is why it catches failures that the link state does not.

The timers

Each side advertises two intervals: the minimum interval at which it wants to transmit, and the minimum at which it is willing to receive. The actual rates are negotiated, and the slower side wins. A third parameter, the detect multiplier, says how many consecutive packets can be missed before the session is declared down. The detection time is roughly the multiplier times the negotiated interval.

Interval	Multiplier	Detection time
1000 ms	3	about 3 s
300 ms	3	about 900 ms
100 ms	3	about 300 ms
50 ms	3	about 150 ms

Shorter is not always better. A multiplier of 3 is a common starting point, and an interval of 300 ms is a reasonable one for software-based implementations.

Transport details

For the common single-hop case, RFC 5881 specifies that BFD control packets use UDP destination port 3784, over both IPv4 and IPv6, and that the TTL (or hop limit) is set to 255. The receiver checks that value, which restricts packets to the directly attached neighbour in the same way as the generalised TTL security mechanism. For paths that cross more than one hop, such as an iBGP session between loopbacks, RFC 5883 uses UDP port 4784. An optional echo function, on UDP port 3785, makes the remote system loop packets back through its forwarding plane. Do not forget these ports in firewall rules: if BFD packets are filtered, the sessions never come up, or they flap.

Configuring BFD with BGP (FRR example)

bfd
 profile fast
  detect-multiplier 3
  receive-interval 300
  transmit-interval 300
 exit
exit

router bgp 64496
 neighbor 2001:db8:ffff::1 remote-as 64511
 neighbor 2001:db8:ffff::1 bfd
 neighbor 2001:db8:ffff::1 bfd profile fast

FRR runs bfdd as a separate daemon and needs it enabled in the daemons file. In BIRD, the BFD protocol is defined separately, and a BGP protocol uses it with bfd on;, with the timers in the protocol bfd block. The names and syntax of options vary between versions, so verify against your documentation. Both ends have to be configured; BFD only starts when the peer also wants it.

To inspect the result:

show bfd peers            # FRR: state, intervals, uptime
show bgp neighbors 2001:db8:ffff::1 | include BFD

A session in state Up with the negotiated intervals you expect is what you want to see. Down or AdminDown, together with the diagnostic code, indicates why a session is not up.

When BFD is the wrong tool

Aggressive timers on a busy CPU. If the router handles BFD in software and is busy, delayed packets can lead to false "down" events, and BFD then causes the flapping it was meant to prevent. Begin with conservative timers, and tighten only after observing stability.
Paths that legitimately jitter. Wireless links, congested tunnels, and long-haul circuits with variable delay do poorly with sub-second timers.
Where recovery is not faster. Detecting a failure in 300 ms is pointless if the rest of the network takes 30 seconds to converge, or if there is no alternate path. In that case BFD gives you an earlier failure and nothing more.
Bundles of links. In link aggregation, a BFD session over the logical interface may not notice a single member failing. RFC 7130 defines BFD on individual member links of a bundle for that purpose, where the hardware supports it.

Interaction with other features

BFD speeds up reaction to failure but does not stop instability. If a link bounces regularly, BFD makes each bounce visible faster. The article on route flapping describes what to do about the sources. It also interacts with graceful restart: some implementations declare BFD down while a neighbour is restarting its control plane, which cancels the benefit of graceful restart, so test combinations before relying on them.

Practical advice

Use BFD on links where a middle device can hide failures, and where you have a real alternative path.
Start with a 3x multiplier and a moderate interval, and confirm both ends agree.
Allow UDP 3784 (and 4784 for multihop) in firewall rules, and restrict them to your neighbours.
Alert on BFD sessions leaving Up, in the same dashboard as BGP state.
Review after any hardware change, since hardware offload can change what timers are safe.

Used selectively, BFD turns a minute-long blackhole into a sub-second reroute.

About IPYE

Disclosure: I run IPYE

ICMPv6 Type by Type: A Reference for What a Firewall Must Allow

IPYE — Mon, 26 Oct 2026 16:23:02 +0000

Disclosure up front: I run IPYE, a company that leases IP space. It gets one short paragraph at the end; the rest is plain networking.

In IPv4, ICMP is a diagnostic extra, and blocking all of it hurts but rarely breaks everything. In IPv6, ICMPv6 is part of the protocol itself: address resolution, router discovery, path MTU discovery, and error reporting all depend on it. A firewall that drops ICMPv6 wholesale produces failures that look random. RFC 4890 ("Recommendations for Filtering ICMPv6 Messages in Firewalls") is the reference for what to permit. This article is a type-by-type table built from it, with the reasoning, plus an nftables sketch. Examples use 2001:db8::/32.

Two families of messages

ICMPv6 (RFC 4443) splits by type number:

Error messages have types 0 to 127: Destination Unreachable (1), Packet Too Big (2), Time Exceeded (3), Parameter Problem (4).
Informational messages have types 128 to 255: Echo Request (128), Echo Reply (129), the Neighbor Discovery family (133 to 137), and multicast listener messages.

Reference table

Type	Name	Scope	Guidance (from RFC 4890)
1	Destination Unreachable	Transit and local	Must not be dropped
2	Packet Too Big	Transit and local	Must not be dropped; path MTU discovery depends on it
3	Time Exceeded (code 0, hop limit)	Transit and local	Must not be dropped; traceroute and loop reporting need it
4	Parameter Problem (codes 1 and 2)	Transit and local	Must not be dropped; code 0 should also be allowed
128	Echo Request	Inbound to your hosts	Allow, ideally rate-limited, for services you want to be testable
129	Echo Reply	Return	Allow for replies to your own pings
133	Router Solicitation	Link-local only	Allow on the local link; never forward off-link
134	Router Advertisement	Link-local only	Allow on the local link, from routers only
135	Neighbor Solicitation	Link-local only	Allow on the local link
136	Neighbor Advertisement	Link-local only	Allow on the local link
137	Redirect	Link-local only	Allow only if you use it; many hosts ignore or disable it
130, 131, 132, 143	Multicast Listener (MLD)	Link-local only	Allow on-link where multicast is used

The principle behind the "transit" versus "link-local" split: error messages and echo cross networks, so they need to pass through border firewalls. Neighbor Discovery and MLD are confined to one link, so they must work on the link but should not cross it.

Why each group matters

Packet Too Big (2). IPv6 routers never fragment, so the sender learns the path MTU only from this message (RFC 8201). Drop it and large transfers hang after the handshake while small packets work. This is the most common ICMPv6 mistake in firewalls.

Destination Unreachable (1) and Time Exceeded (3). Without them, connections to closed ports or dead addresses time out rather than failing fast, and traceroute shows nothing.

Parameter Problem (4). Reports a malformed header or an unrecognised option or Next Header. Code 1 (unrecognised Next Header) and code 2 (unrecognised IPv6 option) are meaningful for upper layers and for extension header handling, so allow them.

Neighbor Discovery (133 to 137). Hosts find each other's link-layer addresses with Neighbor Solicitation and Advertisement, and find routers with Router Solicitation and Advertisement (RFC 4861). Blocking these on a link breaks the link. These messages are sent with a hop limit of 255, and receivers verify it: a packet arriving with a lower value has crossed a router and must be discarded, which is the defence against off-link forgery. Therefore never forward them across links, and do not change hop limits on them.

Echo (128, 129). Allowing inbound echo to servers is a policy choice. Blocking it gains little security and makes diagnosis harder. RFC 4890 suggests allowing it, with rate limits.

MLD (130, 131, 132, 143). Multicast Listener Discovery reports which multicast groups a host listens to. IPv6 Neighbor Discovery uses solicited-node multicast addresses, so MLD matters on switches that do MLD snooping: if the switch does not see the reports, it can prune the multicast traffic that Neighbor Solicitation needs. If you see intermittent neighbor failures on a snooping switch, check MLD.

nftables sketch for a host

This is a starting point for a host input chain; adapt it, and keep the policy default-deny for everything else:

table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;

    ct state established,related accept
    iif lo accept

    # Error messages and path MTU discovery
    icmpv6 type { destination-unreachable, packet-too-big,
                  time-exceeded, parameter-problem } accept

    # Neighbor Discovery: only valid with hop limit 255
    icmpv6 type { nd-router-solicit, nd-router-advert,
                  nd-neighbor-solicit, nd-neighbor-advert } ip6 hoplimit 255 accept

    # Echo, rate-limited
    icmpv6 type echo-request limit rate 10/second accept
  }
}

Hosts that are not routers do not need to accept Router Solicitation, so remove nd-router-solicit there. A router, in turn, needs the forward chain handled separately: allow the error messages and echo to pass, and do not forward the link-local ones. Check the syntax against your nftables version. The rate figure in the example is arbitrary; choose a value for your own traffic.

Rate-limit, do not block

The usual worry about permitting ICMPv6 is abuse. The proportionate response is rate limiting for the types that can be triggered by outsiders, such as echo and error generation, not a blanket drop. Router CPUs also limit how quickly they generate ICMPv6 errors, which is why traceroute and mtr can show missing or slow hops that do not reflect real forwarding problems.

How to test

From a different network, ping -6 your server, then fetch a large page with curl -6 to exercise path MTU discovery. On a link, ndisc6 or ip -6 neigh shows whether Neighbor Discovery works. If anything fails only over IPv6 and only for larger transfers, suspect a drop of Packet Too Big first.

About IPYE

Disclosure: I run IPYE

DHCPv6 Prefix Delegation Explained: How a Router Gets Its Own IPv6 Prefix

IPYE — Mon, 26 Oct 2026 16:22:08 +0000

Disclosure up front: I run IPYE, a company that leases IP space. It gets one short paragraph at the end; the rest is plain networking.

With IPv4, a small-office router usually gets one address and uses NAT for everything behind it. With IPv6, the provider hands the router a whole prefix, which the router subdivides among its internal networks. The standard mechanism is DHCPv6 Prefix Delegation (DHCPv6-PD), defined in the DHCPv6 specification, RFC 8415, which obsoleted the original RFC 3633 for this purpose. This article explains the roles, the message exchange, and the points where it commonly fails. Examples use 2001:db8::/32.

The roles

Delegating router: the provider-side device (often a BNG or an edge router) that owns a pool of prefixes and hands them out.
Requesting router: the customer's router, which asks for a prefix and then uses it on its own downstream interfaces.

Delegation is a lease, not a gift: the prefix has lifetimes, and the delegating router remembers which client holds it. Delegated sizes vary by provider (/48, /56, /60 and /64 all occur), and the requesting router can include a hint of the length it wants, which the server is free to ignore. A /64 delegation leaves room for only one downstream network.

The message exchange

DHCPv6 clients use UDP port 546 and servers and relays use UDP port 547. The client begins by sending to the link-local multicast address ff02::1:2 (All_DHCP_Relay_Agents_and_Servers). The four-message exchange is:

Message	Direction	Purpose
Solicit	client to server	"Is any delegating router there?" It carries an IA_PD option, which is the request for a prefix
Advertise	server to client	Offers a prefix, with lifetimes
Request	client to server	Asks for the offered prefix from a chosen server
Reply	server to client	Confirms; the client now holds the prefix

RFC 8415 also defines a two-message variant using Rapid Commit. Afterwards the client uses Renew (extend the lease with the same server), Rebind (ask any server) and Release (give the prefix back). The option that carries the prefix is IA_PD, which contains one or more IAPREFIX entries with the prefix, its length and two lifetimes:

Preferred lifetime: how long the prefix should be used for new communication.
Valid lifetime: how long it remains usable at all.

The IA_PD also carries timers T1 and T2 which tell the client when to try Renew and Rebind respectively. If the client cannot renew before the valid lifetime ends, it must stop using the prefix.

What happens after the prefix arrives

Receiving a prefix does not configure anything by itself. The requesting router must then:

Split the delegated prefix into /64s, one per downstream interface (a /56 yields 256, a /60 yields 16).
Assign an address to each downstream interface from its /64.
Advertise each /64 to its LAN with Router Advertisements (RFC 4861) so hosts can use SLAAC (RFC 4862), or run a DHCPv6 server for stateful addressing.

Hosts on those LANs never see DHCPv6-PD; they see ordinary Router Advertisements. The requesting router also needs its own WAN-side address and default route, and DHCPv6 does not provide a default gateway: that comes from a Router Advertisement on the WAN link, while the WAN address may come from SLAAC or a DHCPv6 IA_NA request. RFC 7084 lists these behaviours for IPv6 customer edge routers.

The M and O flags in Router Advertisements

Router Advertisements carry two flags: M ("managed address configuration") says to use DHCPv6 for addresses, and O ("other configuration") says to use DHCPv6 for other information such as DNS servers. They do not control prefix delegation. A requesting router asks for a prefix because it is configured to, not because of an RA flag, so a missing M or O flag is not the explanation if PD fails.

The routing step that is easy to miss

The delegating router must be able to send traffic for the delegated prefix to the requesting router. That requires a route: delegated prefix, next hop the client's link-local (or WAN) address. Some servers install it automatically; others rely on a script, a relay, or a manual static route. If a client holds a prefix but nothing outside can reach hosts in it, check for this route first. Equally, the requesting router must not send unused parts of the delegated prefix back out its WAN, or traffic may loop; many CE routers install an unreachable route for the whole prefix, with more specific routes for the subnets in use.

A configuration example (systemd-networkd)

With systemd-networkd, the WAN side requests a prefix and the LAN side receives a subnet of it. The exact option names have changed between releases, so check the documentation of your version:

# /etc/systemd/network/10-wan.network
[Match]
Name=wan0
[Network]
DHCP=ipv6
IPv6AcceptRA=yes

# /etc/systemd/network/20-lan.network
[Match]
Name=lan0
[Network]
DHCPPrefixDelegation=yes
IPv6SendRA=yes

Other clients, such as dhcpcd or wide-dhcpv6-client, use different syntax; on the server side, ISC Kea supports prefix delegation pools.

Debugging

Capture the exchange: tcpdump -ni wan0 'udp port 546 or udp port 547'. You should see Solicit, Advertise, Request, Reply. If you see only Solicit, nothing is answering on that link.
If Advertise arrives with a status code other than success inside the IA_PD, such as NoPrefixAvail, the server has no prefix to give or the request does not match its configuration.
Check what you hold with ip -6 addr and ip -6 route.
If hosts have addresses but no connectivity, test routes in both directions and check that the firewall allows DHCPv6 and ICMPv6.
Prefixes can change when a lease lapses or a link is reset, depending on the provider's policy. A server may, but need not, hand the same prefix back to a returning client, so do not hard-code delegated prefixes into DNS or firewall rules.

Summary

The common failure points are a delegated prefix too small for the networks you need, a missing route on the delegating side, and renewal problems when the WAN link flaps.

About IPYE

Disclosure: I run IPYE

IPv6 for Web Servers: Dual-Stack nginx and Apache, and How to Test It

IPYE — Mon, 26 Oct 2026 14:48:56 +0000

Disclosure up front: I run IPYE, a company that leases IP space. It gets one short paragraph at the end; the rest is plain networking.

Adding IPv6 to a web server is mostly four small jobs: put an address on the host, make the web server listen on it, publish an AAAA record, and let the traffic through the firewall. Each step has a common mistake, and the worst one, publishing the AAAA record before the other steps work, breaks the site for IPv6 visitors. This article walks through nginx and Apache and then shows how to test each layer separately. Examples use 2001:db8:100::10 for the server and www.example.com for the site.

Step 1: the address and route

Confirm the host has the address and a default route before touching the web server:

ip -6 addr show dev eth0
ip -6 route show default
ping -6 -c 3 2001:db8:100::1     # the gateway

If the provider gave you a /64 or larger, configure 2001:db8:100::10 with a prefix length that matches the subnet (typically /64) and the gateway they specify.

Step 2: nginx

nginx listens per address family, so you add an IPv6 listen directive next to each IPv4 one:

server {
    listen 80;
    listen [::]:80;
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name www.example.com;

    ssl_certificate     /etc/ssl/example/fullchain.pem;
    ssl_certificate_key /etc/ssl/example/privkey.pem;
    ...
}

Details that cause trouble:

On Linux, listen [::]:80; by default creates an IPv6-only socket (the ipv6only=on default). That is what you want, since listen 80; already covers IPv4. Writing [::]:80 ipv6only=off and also listen 80; conflicts and nginx reports "address already in use".
The ipv6only parameter can be set only once for a given port, on the first listen that defines it. Parameters such as default_server apply per listen directive, so if you mark the IPv4 listener of a block as the default, mark its IPv6 listener too.
Access rules accept IPv6 syntax directly: allow 2001:db8:200::/48;. A rule list that only has IPv4 entries silently allows or denies IPv6 clients according to the final deny all, so review each.
Behind a proxy or load balancer, set real_ip_header and set_real_ip_from with both IPv4 and IPv6 ranges of the proxy, or your logs will show the proxy's address.

Check and reload with nginx -t && systemctl reload nginx.

Step 3: Apache

Apache's Listen directive without an address, such as Listen 80, binds to all interfaces. On Linux that normally includes IPv6, with IPv4 connections handled through the same dual-stack socket. To be explicit, or to bind specific addresses, give them separately:

Listen 192.0.2.10:443
Listen [2001:db8:100::10]:443

<VirtualHost 192.0.2.10:443 [2001:db8:100::10]:443>
    ServerName www.example.com
    SSLEngine on
    SSLCertificateFile    /etc/ssl/example/fullchain.pem
    SSLCertificateKeyFile /etc/ssl/example/privkey.pem
</VirtualHost>

If you use <VirtualHost *:443>, the wildcard already matches IPv6. Address-based access rules use Require ip 2001:db8:200::/48. Validate with apachectl configtest.

Step 4: the firewall

Open the same ports in the IPv6 ruleset. It is common to see iptables rules for 80 and 443 with nothing in ip6tables, or an nftables ip table without an ip6 or inet equivalent. Also keep ICMPv6 (Packet Too Big, in particular) working, otherwise some clients will connect and then hang on large responses.

Step 5: test before publishing the AAAA record

Do not add DNS yet. Test the server by address, with the right hostname, so TLS and virtual hosts still match:

ss -tlnp | grep -E ':(80|443)\b'
curl -6 -I --resolve www.example.com:443:[2001:db8:100::10] https://www.example.com/

ss should show a listener on [::]:443 (or the specific IPv6 address). --resolve makes curl connect to the given address while still sending www.example.com in the SNI field and Host header; the brackets are required for IPv6 literals. Test from a different network than the server, since local tests can succeed through the loopback path and miss firewall problems.

Step 6: publish the AAAA record

Add the record with a modest TTL so you can pull it back quickly:

www.example.com.  300  IN  AAAA  2001:db8:100::10

Then query it and test through normal resolution:

dig +short AAAA www.example.com
curl -6 -sS -o /dev/null -w '%{remote_ip} %{http_code}\n' https://www.example.com/
curl -4 -sS -o /dev/null -w '%{remote_ip} %{http_code}\n' https://www.example.com/

Both should return a success code. The two address families should serve identical content: run both checks and compare. Also check that the certificate is the same, since a stray default server on only one family can present a different certificate.

Things that break only on IPv6

Applications that store or validate IP addresses. Database columns sized for 15 characters, regular expressions that accept only dotted quads, and libraries that mis-parse a colon as a port separator all show up once IPv6 clients arrive. A full textual IPv6 address can be 39 characters long, and forms with an embedded IPv4 address reach 45.
Rate limiting and bans. One IPv6 user commonly has a /64 or more, so limits keyed on a single /128 are easy to evade. Aggregate by /64 where that fits your policy.
Logging and analytics. Log parsers and fail2ban rules need IPv6 patterns. Make sure ban actions apply to ip6 firewall tables.
Reverse DNS. Mail servers and some services check PTR records; delegate and set ip6.arpa entries for addresses that send mail.
Hard-coded addresses in configuration or allow lists.

Rolling back

If IPv6 users have trouble, remove the AAAA record. Clients fall back to IPv4 once cached records expire. A low TTL during rollout shortens that window, and you can raise it again once the service has been stable.

About IPYE

IPYE (https://my.ipye.com) offers leased IPv4, IPv6, and ASN space. The first year of a /48 IPv6 block is free, and IPYE handles LOA, ROA, rDNS, and WHOIS. Locations: Los Angeles, New York, Ashburn, Salt Lake City, London, Amsterdam, and Frankfurt. Questions: ipye@turnel.com.

Disclosure: I run IPYE

Dual-Stack Hygiene: Happy Eyeballs, MTU and Path MTU Discovery, and the ICMPv6 You Must Not Filter

IPYE — Mon, 26 Oct 2026 14:09:34 +0000

Disclosure up front: I run IPYE, a company that leases IP space. It gets one short paragraph at the end; the rest is plain networking.

Dual-stack service, where a host answers on both IPv4 and IPv6, usually works because clients are forgiving. That forgiveness can hide faults, such as an IPv6 path that silently drops large packets. This article covers three things that often go wrong: how clients choose between address families, how packet size is negotiated, and which ICMPv6 messages a firewall has to let through. Examples use documentation addresses: 2001:db8::/32 and 192.0.2.0/24.

Happy Eyeballs: why clients usually cope

When a client resolves a name with both A and AAAA records, default address selection (RFC 6724) generally prefers IPv6. Happy Eyeballs (RFC 6555, updated by version 2 in RFC 8305) stops a broken IPv6 path from making users wait for a full TCP timeout. In outline, RFC 8305 describes:

Sending the AAAA and A queries together, and giving the AAAA answer a short head start, the Resolution Delay, recommended at 50 ms.
Starting connection attempts in turn rather than all at once, with a Connection Attempt Delay recommended at 250 ms, with a minimum of 100 ms and a maximum of 2 seconds.
Using whichever attempt completes first and cancelling the rest.

Implementations differ, and some simpler clients fall back slowly or not at all. The lesson for a server operator: Happy Eyeballs makes IPv6 faults less visible, not absent. A user on a bad IPv6 path may see a delay on every new connection and never report it.

Operator habits that follow from this:

Publish AAAA only for services you run and test on IPv6. Do not remove the AAAA record to "fix" a problem you have not diagnosed; fix the path.
Test and monitor each family on its own. curl -4 https://example.com/ and curl -6 https://example.com/ isolate the problem.

MTU and path MTU discovery

The link MTU is the largest packet a link can carry. Ethernet is typically 1500 bytes. The two IP versions handle oversize packets differently:

IPv4: a router may fragment a packet unless the Don't Fragment (DF) bit is set. Most modern TCP stacks set DF and rely on Path MTU Discovery (RFC 1191): a router that cannot forward a DF packet returns ICMP type 3, code 4 ("Fragmentation Needed").
IPv6: routers never fragment. Only the source can, and every link must support at least 1280 bytes (RFC 8200). A router that cannot forward a packet sends ICMPv6 type 2, "Packet Too Big", carrying the next-hop MTU (RFC 8201).

So IPv6 depends on Packet Too Big messages even more than IPv4 depends on its equivalent, because there is no router-side fragmentation to fall back on. If a firewall drops those messages, the sender never learns the real limit. Small packets (the TCP handshake, a short HTTP request) work; larger ones vanish. The symptom is a connection that stalls after the handshake or hangs during a TLS exchange or a large download. This is a PMTUD black hole. RFC 4821 describes packetization-layer discovery as a mitigation, but it is slower and no substitute for letting the errors through.

Common sources of a smaller MTU

Path element	Typical effect
PPPoE	8 bytes overhead, so 1492
6in4 tunnel (protocol 41)	20 bytes over IPv4, so 1480
GRE over IPv4	24 bytes, so 1476
WireGuard	60 bytes over IPv4 or 80 over IPv6; default interface MTU of 1420 covers the larger case

MSS clamping

TCP's Maximum Segment Size excludes the IP and TCP headers. For a 1500-byte MTU the MSS is 1460 over IPv4 (1500 minus 20 minus 20) and 1440 over IPv6 (1500 minus 40 minus 20). On a router in front of a tunnel or PPPoE link, clamping the MSS in the SYN packets avoids the problem for TCP even if ICMP is lost. On Linux with nftables, tcp option maxseg size set rt mtu in a forward chain does this. It is a safety net, not a reason to filter ICMP, and it does nothing for UDP.

ICMPv6 you must not filter

Neighbor discovery, the IPv6 replacement for ARP, runs on ICMPv6, so blanket ICMP filtering breaks more than diagnostics. RFC 4890 gives filtering recommendations; the essentials:

Type 1, Destination Unreachable (all codes), type 2, Packet Too Big, type 3, Time Exceeded, and type 4, Parameter Problem: these are the error messages. Dropping them causes black holes and slow failures.
Types 133 to 137, Router Solicitation and Advertisement, Neighbor Solicitation and Advertisement, Redirect: required on the local link. Without neighbor solicitation and advertisement, hosts cannot resolve each other's addresses. Discard ND packets with a hop limit other than 255, which proves they did not cross a router.
Types 128 and 129, Echo Request and Reply: RFC 4890 recommends permitting these to your servers, optionally rate-limited.

A host firewall sketch in nftables, placed in a table inet filter input chain with a default drop policy:

ct state established,related accept
meta l4proto ipv6-icmp icmpv6 type { destination-unreachable, packet-too-big, time-exceeded, parameter-problem, echo-request, nd-router-solicit, nd-router-advert, nd-neighbor-solicit, nd-neighbor-advert } accept
meta l4proto icmp icmp type { destination-unreachable, time-exceeded, echo-request } accept

A router's forward chain needs the error types too. Connection tracking usually marks matching ICMP errors related, but an explicit rule is clearer.

Verification

Probe with DF set: ping -6 -M do -s 1452 2001:db8::10 sends a 1500-byte packet (1452 data plus 8 ICMPv6 and 40 IPv6 header bytes). For IPv4, use -s 1472 with 192.0.2.10. Lower the size until it succeeds.
tracepath -6 reports the path MTU it finds hop by hop, and ip route get 2001:db8::10 shows a cached MTU after a Packet Too Big arrives.
Capture: run tcpdump -ni eth0 icmp6 during a stall. If Packet Too Big never arrives, something upstream is dropping it.
Compare families: if curl -4 works and curl -6 stalls on large responses, suspect MTU first.

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

Reading a Looking Glass and BGP Route Data to Debug an Unreachable Prefix

IPYE — Mon, 26 Oct 2026 13:46:04 +0000

Disclosure up front: I run IPYE, a company that leases IP space. It gets one short paragraph at the end; the rest is plain networking.

"My prefix is announced but nobody can reach it" is one of the most common BGP support questions, and the answer is almost never found by staring at your own router. You need outside views of the routing system. This article walks through a repeatable order of checks using public tools: route collectors (RIPE RIS, RouteViews), RIPEstat, bgp.tools, and the looking glasses that many networks publish. Examples use documentation values (AS64496, 2001:db8:abcd::/48).

First, split the problem in two

Reachability has two halves, and they fail differently:

Control plane: does the world have a route to your prefix, with your ASN as origin?
Data plane: if packets arrive, does a host answer, and can the replies get back?

Check the control plane first. If outside vantage points see no route, nothing downstream matters. If they do see it, the problem is usually on your side of the edge.

Step 1: Is the prefix visible at all?

Search for the exact prefix in RIPEstat (the "Routing status" and "BGP looking glass" widgets) or on the bgp.tools prefix page. You want to see:

The prefix listed as announced, with your ASN as the origin.
It is seen by many collector peers, not just one or two. A prefix seen by only a handful of peers has usually been accepted by one upstream and stopped there, often because of a filter further along.
The first-seen/last-seen or routing history is sensible. A prefix that appears and disappears repeatedly points to a flapping session or a flapping static route feeding the export.

If it is missing entirely, go back to your router: is the session Established, is the route in the export table (show route export or the equivalent), and does your export policy actually match the prefix and its length?

Step 2: Read the AS path

Every route in a looking glass shows an AS path, read from the neighbor on the left to the origin on the right. For example:

AS_PATH: 64510 64497 64496

means the observer learned the route via AS64510, which learned it from AS64497, which learned it from the origin AS64496. Things to look for:

The origin (rightmost) AS is yours. A different origin means someone else is announcing the prefix, or a provider is originating on your behalf, and ROA/IRR data may not match.
Unexpected intermediate ASNs. If your path goes through a network you do not buy transit from, you may have a leak or a surprising peering relationship.
Excessive prepending. A heavily prepended path loses to shorter alternatives, which can move traffic in ways you did not intend.

Step 3: Compare vantage points

Run the same lookup from several looking glasses: one in your upstream's network, one at a large transit network, one on a different continent. The pattern tells you where the problem is:

Visible at your upstream, nowhere else: the upstream is not exporting you onward. Usually an IRR or prefix-filter update is pending, or the prefix was not on their customer filter.
Visible widely but missing in one network: that network is filtering you, commonly because of RPKI-invalid status, a missing or mismatched IRR object, or a prefix length they do not accept.

Step 4: Check RPKI and IRR status

Both RIPEstat and bgp.tools show RPKI validation state for the prefix and origin pair. Invalid is the one that bites: networks doing route origin validation (RFC 6811) commonly drop it. Invalid means a ROA covers the prefix but the origin ASN differs or the announced length exceeds maxLength. NotFound means no ROA exists and is usually still accepted. Then check that an IRR route6 object exists with your origin ASN, because many providers still build prefix lists from IRR data.

Step 5: Check the length

Large networks commonly filter IPv6 announcements more specific than /48 and IPv4 announcements more specific than /24. This is convention, not a protocol rule, but it is widely followed. If you announce a /56 or a /25, expect it to be absent from most looking glasses. Also look for more-specific prefixes announced by someone else: they win longest-prefix match regardless of your announcement.

Step 6: Use the looking glass for the data plane

Most looking glasses allow ping and traceroute as well as show route. From a vantage point that has a valid route:

Ping and traceroute to a specific address inside the prefix, not the network address.
See where the trace stops. If it reaches your upstream and then dies, check that the address is actually configured and that the route inside your network points to it.
Test the return path: from your host, traceroute back to the looking glass's source. Asymmetric routing is normal, but a missing or filtered return route makes everything look broken.

Step 7: Local causes once the control plane is clean

If the world has a valid route and paths look right, work through the usual suspects:

Nothing owns the address. Announcing a prefix that points at no configured host is the classic case. Check the address is assigned and the router has a route toward it.
Host or edge firewall dropping inbound traffic, especially ICMPv6, which IPv6 needs for neighbor discovery and path MTU discovery.
IPv6 not enabled on the session or on the service itself (a listener bound only to IPv4).

Report what you saw

Write down the result of each step. Provider support teams respond much faster to "prefix X is seen by upstream Y but not by network Z, path below" than to "BGP is broken."

About IPYE

Disclosure: I run IPYE