An IPv6 address in your logs: which block do you actually write down?

What actually arrived, and why it is not four octets with more digits

The line gives you an address, a time and whatever your own system chose to keep. Three habits come next: block the address, look up its /24, mail the abuse contact. The second has no IPv6 translation at all, because there is no default width to fall back on. On IPv4 the /24 is a floor a reader borrows from routing practice, and that floor is about propagation rather than tenancy.

What you are holding is 128 bits, and the architecture has already spent half of them on something that tells you nothing. RFC 4291, the IPv6 addressing architecture, requires interface identifiers to be "64 bits long" for every unicast address except those beginning with the binary value 000, and the space global addresses are handed out of does not begin with those bits. So the rightmost half of the address is the host's own side of the boundary. A later standard says what that half is worth to a reader in one line: the entire identifier "should be treated as an opaque value". That is why a host address in IPv6 says less about a subscriber than an IPv4 address does, not more.

The left half is not a boundary either. RFC 4291 splits it into a routing prefix and a subnet identifier, constrains only their sum and gives neither of them a value anywhere. Nothing in that format names a subscriber, a customer or a provider. The only party the format describes is a site, glossed as a cluster of subnets and links. So the address arrives carrying a fixed line between network and host, and no line at all between one network's customer and the next.

One instruction before any of the reading: capture the whole line now. What a usable record of an event contains is its own post, and the IPv6 reason for urgency is specific. The address may not be reachable, or in use, or the same host's, tomorrow, and there is no wider thing you can write down instead and still be right. Everything below is about which wider thing you are entitled to write down. The report offers four places to look, and the next section walks them in the order the page prints them.

One address, four places, and not always four blocks

Take a real consumer broadband allocation as the worked subject, because that is the kind of space a log line actually comes from. Typing 2a02:8109:a1c0::/48 into a lookup on 19 September 2026 filled all four slots on one page with three different blocks, because the fourth printed one of the other three back.

One, the block you typed. The sampling panel's heading does not repeat the block, it gives the block's size: Address sampling followed by the number of addresses sampled out of 1,208,925,819,614,629,174,706,176, which is what a /48 holds. The block itself is named in the line beneath, which is the line the panel swaps for one about grouping once the sample grows. Type a single address instead and the same heading reads that it is sampling this exact address, again without printing it. Either way the heading is doing real work: it is the panel telling you which object every figure beneath it is about.

Two, what is announced. The Routing panel prints a Routed prefix row reading 2a02:8109:8000::/33, beside an Origin AS row naming two networks. That row is drawn only because the announced prefix is not the one typed, so its presence is itself a reading: what carries this address across the internet is a far wider block than the one you asked about. On the second worked subject, Cloudflare's 2606:4700:4700::/64, the same row reads 2606:4700:4700::/48. In both cases the announcement is the network's decision about routing and says nothing about who inside it holds what.

Three, what is registered. The Registration panel heads itself with a block whenever that block is not the one you typed, and on the consumer subject it is 2a02:8108::/31, whose Addresses row reads 158,456,325,028,528,675,187,087,900,672. Its Type reads AGGREGATED-BY-LIR, which is the registry's own vocabulary for a block whose individual assignments are not published as separate objects, and its Abuse contact is a single mailbox. Say that plainly, because it is the whole of row three in the table below: one mailbox stands behind every address in a block of that size, and the type string is the record saying so. On the Cloudflare subject the registered block is a /32 and the type reads DIRECT ALLOCATION, a different shape of the same fact: the registry names what it handed to a network, never what the network handed on. What each status string means is covered elsewhere and the IPv6 vocabulary is its own list.

Four, the layer above. The Registration panel closes on a collapsed Enclosing blocks table with a count beside its name, holding whatever the registry's hierarchy returned. On the consumer subject that is a single row, and the row is the /31 the heading has just named, so the fourth place answers with the third. On the Cloudflare subject it is a single row covering the whole of IPv6, a placeholder rather than a parent, and the finding that would name a real parent does not fire there at all. That this table is a read on one registry's hierarchy, and can hold a placeholder, was published on 17 September. The IPv6 face of it is worth one sentence: the Less specific row that post reads as always on screen on IPv4 outside RIPE space was absent from the Routing panel on both subjects here, so nothing on either Routing panel read the hierarchy at all.

Three different blocks on the consumer subject, in width order: a /31 registered, a /33 announced and the /48 typed, with one address somewhere inside. The /31 is also the only row in the enclosing table. Every one of them is a real object with a real record behind it, and not one of them is the piece of space one subscriber holds. When you aim at the right level of the registration hierarchy, that is the level these answer for. The subscriber's own boundary is the subject of the next section, and it is the only one of the five that decides what a rule catches.

The fifth boundary, the one that decides the rule

Every act in the ticket turns on how much space one subscriber holds. Write a rule narrower than that and it catches part of one subscriber's space; write it wider and it catches their neighbours. On IPv4 the question rarely arises, because a residential customer usually holds one address. On IPv6 it is the whole problem, and the answer is not printed on any of the four places above.

Start with what the standards do. RFC 6177, published in March 2011 as BCP 157, obsoleted the earlier recommendation that end sites be assigned /48 blocks in most cases, on the stated ground that "a one-size-fits-all recommendation of /48 is not nuanced enough". It declines to put another number in its place, saying in terms that it makes no formal recommendation on what the exact assignment size should be and that the choice is an issue for the operational community. It adds two things to hold together. Architecturally, "anything of length /64 or shorter works". Practically, an end site should be able to obtain "a block larger than a single /64". The same document asks that there be no hard-coded boundaries inside addresses at all, which is the opposite of the habit a reader arrives with.

Then what the registries do, and here the post can only speak for the two policies it read. In the RIPE region, ripe-738 of 16 March 2020 makes registration of IPv6 assignments mandatory in its section 5.5 and gives two routes: individual assignment objects, or one aggregated object carrying an assignment-size attribute that holds the size of the End User assignments inside it. The size itself is a local decision for the provider, and that region's own operational guidance, ripe-690 of 16 October 2017, recommends a /48 for each end user in a simple plan, or a /48 for business and a /56 for residential, and states that assigning a /64 or longer does not conform to IPv6 standards and will break functionality in customer LANs. In the APNIC region, apnic-127 of 20 February 2025 requires in its section 5.3.1 that a delegation wider than a /48 be registered, while a /48 or narrower may be registered at the discretion of the internet registry and the network administrator. So across those two, a declared size is published by rule in one region, published by rule only above a certain size in the other and nowhere derivable from the address itself. Which regions require what, and what a missing record innocently means, is the registration comparison the reassignment post already carries.

The consumer subject shows what the aggregated route looks like from outside. Its registered block carries the aggregated status, and the registry record behind it carries assignment-size, reading 56. That is the answer the record gives: the declared size of the assignments inside that block is a /56. Where it sits matters more than the number. No panel draws that attribute. It reaches the report only in the raw JSON, under Raw JSON response at the foot of the Sources panel, where the registry's own keys and values sit under the registration object, which is where the layer above survived on the ARIN subject that post read and where two other regions published no parent key at all. An outsider reading the page will not find it. An outsider who opens that JSON will, and what they will have is the provider's own declaration of a uniform assignment size, which is a fact about the block and not a fact about the customer behind any one address in it.

Which leaves the /64, and the reason it keeps turning up. It is not a delegation and never was. It is where the addressing architecture puts the interface identifier, and the consequence, in the analysis the IETF published of that very boundary, is that fixing the identifier at 64 bits fixes the subnet at /64 "regardless of the aggregate prefix", while routing itself carries prefixes of any length. The blocklists then picked it as a listing unit, which the widening post already records, along with the hosting and sending guidance that tells hosts to give each hosting customer a separate /64. That guidance sizes a sending customer rather than the home network the regional guidance sizes, which is why the same number turns up on both sides of the question. So an outsider who writes a /64 rule is aiming at one segment of what the worked record declares to be a /56, and an outsider who widens without reading that declaration is choosing between sizes that differ by two hundred and fifty six to one. The record makes neither choice wrong. Each is a choice, and the ticket should say which one was made and why.

Of the three places a reader might turn to for that boundary, only one says anything about it at all. The registry names what it allocated and, where the rules bite, the declared size of the assignments inside, never which customer sits where. Routing carries what a network chose to announce, and it will carry anything: on 2001:67c:2e8::/48, a registry's own infrastructure block, the origin history holds the holder's own announcement of the /48, first seen on 28 September 2010 and current, with three periods printed beneath the row rather than one unbroken run, and below that a single /128 announced between 2 and 13 February 2021 by a network that is not the holder. And a geofeed carries location rather than tenancy. The boundary is declined by the standards, delegated by the registries and absent from the routing table, which is a different thing from hidden.

The address may already have been retired when it reached you

The rule question here is settled elsewhere: a rule against a single IPv6 address can expire on its own before anyone reviews it, because of the default lifetimes a host applies to the temporary addresses it generates. What that post does not take up is the evidence question, which is the one an outsider holding a log line has.

A host generating temporary addresses makes them for its own outbound connections and retires them, so the identifier in your log names a host for a window rather than naming a tenancy. The same machine may be back tomorrow under a different address, and where the provider's prefix is persistent it will be sitting in exactly the same subscriber space. The opposite shape exists too: a separate standard describes stable, opaque, per-prefix identifiers that do not change while the host stays on that network. Both are designed so that nothing can be read off the bits, and from the address alone an outsider cannot tell which of the two they are holding. That is not a gap in the record, it is the design working.

One more thing follows, and it matters for any count in a write-up. A host is expected to hold more than one address at a time, which is written down as current practice rather than as an edge case. So a tally of distinct addresses in a log overstates the number of machines, and on IPv6 it can overstate it badly. Two consequences for what you write. The rightmost 64 bits are not an identifier to carry forward into a conclusion. And the sentence in the ticket has to name the address and the time together, because the address alone is a claim about a window somebody else controls. Everything the report shows about that address is a reading with its own date, and reading today's reputation onto last month's event is the error naming both together exists to prevent.

The report answers about the object in the box

One rule holds this section together: every panel answers about the thing you typed, and on IPv6 the thing you typed is almost never the thing that is announced or the thing that is registered. Three demonstrations, all from lookups run on 19 September 2026.

The first is the RPKI row, and it is the sharpest thing on the page. Type Cloudflare's resolver block as a /64 and the Routing panel's RPKI row reads invalid_length. Type a single address inside that same block and the row reads valid. Type the announced /48 and it reads valid. Nothing about the network changed between those three lookups, and the collapsed Validating ROAs table beneath the row is where the reason sits: it carries the prefix the ROA covers, the origin, the maximum length and a Validity column, and where one ROA covers the block that column moves with the row. The consumer subject flips the same way on the row, reading invalid_length for the /48 that was typed and valid for the /33 that is actually announced, but its table carries two ROAs and only one of them turns: beneath a row reading valid, the second still reads invalid_length. So the status is an answer about the prefix in the search box and not a verdict on the holder, and on IPv6, where the block you have is routinely longer than the block anyone signed, it is the ordinary answer rather than an unusual one. Why an announcement longer than the ROA allows reads invalid and what each status means are covered there, and the remedy belongs to a holder rather than to you.

The second is what does not draw. What the Origin history panel prints for a block carried only inside a wider announcement, and why it gets no Time machine, was published on 14 September for an IPv4 slice. The IPv6 face is the part worth adding: because delegations sit far below anything a network announces, this is the ordinary case on IPv6 rather than the exception it is on IPv4. It is not universal. The registry infrastructure block named above does draw a Time machine, because the /48 itself is announced in its own right rather than only carried. Which of the two you are looking at is visible on the page, and it is the difference between a block with a dated history and a block with none. The same panel holds what carried the block without originating it: covering routes sit in Origin history and not in Routing, in a closed section whose summary reads transit rather than control.

The third is the denominator, which is where an analyst is most likely to read confidence that is not there. The sampling panel prints how many addresses were sampled out of the total, and on the consumer /48 the block map legend prints the remainder not sampled yet, a figure the handful of sampled addresses barely moves off the total and one that changes only as more addresses inside the block get looked up. A report that put a percentage there instead would be claiming a measurement it did not make. The page says the rest in its own words: that it was checked in one month only and no other month in the last twelve was checked, and that score history starts here with a single reading recorded on the day it was looked up, a trend appearing once these addresses have been checked on more than one day. Read that the way it is written. On a block this size a sample is an existence proof and never a proportion, so a clean sample supports no sentence at all about the block, and no verdict is not innocence. The word for that state is unknown rather than clean, and on IPv6 most blocks sit there.

Which width belongs to which act

The discipline the table implements is not this post's. Pick the narrowest width the evidence supports, write down what you would need to see to widen it, and give wider rules shorter review intervals than narrow ones: that is already published, along with the finding, dated 23 August 2026 and scoped to the documents that post names, that none of them sets a numeric threshold for when to widen. This table is that discipline applied to a family where the narrowest width is also the one most likely to expire by itself, and where the width above it has to be read off a record or guessed. Every row ends in what the act leaves unestablished, never in an instruction to a network.

One move the table cannot show. That a narrow rule keeps being evaded does not by itself establish that a wider one is warranted, and what a control at the same width costs against what a wider block costs is already weighed there. On IPv6 the weighing matters more than it does on IPv4, because the step up from the address is not a step to two hundred and fifty five neighbours but to a number with twenty digits in it, and the step after that is a reading or a guess.

What the report will never settle

Four limits, each a property of the record rather than an apology. The first is the delegation boundary. Where a region requires it, the provider's declared assignment size is on the registry record and reaches the report only under Raw JSON response; where it does not, it may never have been written down at all. Either way the report can date what was announced and what was allocated, and it can never say who is behind the space around one address or whether that space was assigned to anyone.

The second is the sample. The denominator is printed, the empty months are printed, and on a block whose size runs to twenty five digits neither can be turned into a proportion, so the block's own state stays unknown however clean the readings are. That is a property of a block that size rather than of a shallow check.

The third is the archive. It begins the first time somebody looked the resource up here, which the page says in its own words, and nothing watches, re-checks on anyone's behalf or notifies anybody afterwards. That is stated for a holder running their own schedule and it is doubly true for an outsider, who has no standing to ask for anything and no reason to be told.

The fourth is reverse DNS. The report carries none at all, no PTR and no hostname, so the question a mail case most often wants answered is not answerable on this page and belongs where the delegation itself lives. What a single address investigation cannot reach is the general version of all four, and an address that belongs to infrastructure rather than to a person is the case where they bite hardest. The write-up that survives review names the address, the time, the width of the rule and the reason that width was chosen, and says which of the four places each claim is reading from.

Reading it on the report

Type the address itself first, for the reading that is about that address, then follow the report's own links to the registered block and the announced prefix, which are the two blocks the page hands you. On every one of those lookups read the headings before the rows. The sampling heading counts the object rather than naming it, reading a number of addresses out of the size of the block, or on a single address that it is sampling this exact address, and until the panel starts grouping its cells the line under it names the object. The Routed prefix row appears only when what is announced differs from what you typed. The Registration heading names the block the registry serves whenever that is not the one you typed. The Enclosing blocks summary counts whatever the hierarchy returned above it, which on the consumer subject was the registered block over again. Four places to read, three different blocks on the consumer subject, one address. Anyone doing this on every ticket can run the same lookups through the free keyless JSON API at https://subnethistory.com/api/v1/lookup?q=, whose limits are on the docs, and why an IPv6 block is worth reading at all is its own argument.