Summary

  • NANOG’s public wireless design evolved from protected and open legacy choices in 2015–2019 to a recurring three-SSID pattern by 2022: a protected main network, an open compatibility network and an open IPv6-only network.
  • Notices from NANOG 89 to NANOG 97 repeatedly describe those choices, name changing connectivity, wireless and edge-routing contributors, and provide a support contact. They do not publish topology, failover, uptime, client success, incident or teardown results.
  • The IPv6-only label establishes a real client-facing test surface, but it does not show whether NAT64 or DNS64 was present, whether IPv4-only destinations were reachable, or how many devices and applications worked.
  • A proportionate public record would be a short post-meeting operational note with aggregate service denominators, material incidents, provider roles, the intended IPv6 reachability model and a retention/teardown statement—not raw logs, client identifiers or exploitable configurations.

The menu is the contract

Conference Wi-Fi instructions are usually read once and forgotten. NANOG’s notices deserve a closer look because their repetition turns a transient instruction into an institutional choice. The NANOG 97 welcome message names Ziply Fiber for Internet connectivity and HPE for edge routing, then offers three SSIDs. NANOG uses WPA3 and the shared key nanognanog. NANOG-Legacy is open and unencrypted on 2.4 and 5 GHz. NANOG-V6 Only is also open and unencrypted, with no IPv4 or DHCP.

The daily messages during the meeting repeat the same choices. That matters. A pre-event message might describe an intended configuration; an in-event reminder shows what the organiser was still telling attendees to use. Neither proves that association succeeded or traffic flowed, but together they establish the advertised access surface.

Each line has a distinct function. The main SSID is the protected default. The legacy SSID preserves compatibility for equipment or software that cannot use the preferred mode. The IPv6-only SSID makes a protocol constraint visible to the client instead of hiding it inside the network. These are not three quality tiers. They are three different allocations of compatibility, link-layer protection and experimentation.

That is why the word “contract” is useful if kept modest. It is not a legal service-level agreement. It is an attendee-facing representation: choose this name and NANOG says these basic conditions apply. The representation is testable at the association edge. A user can see whether a network is advertised, whether it asks for the published credential and whether an IPv4 lease appears. But the notice does not specify enough to answer whether the service was reliable, secure end to end or compatible with a user’s applications.

The distinction is central. An access menu tells people how to enter. An operating report tells them what happened after entry. NANOG publishes the first consistently. In the material reviewed for this article, it does not publish the second with comparable regularity.

From frequency bands to protocol choice

The present pattern did not appear fully formed. A January 2015 attendee notice said NANOG was trying to simplify and standardise meeting wireless information. It separated a protected 5 GHz network, a protected 2.4 GHz network and an open legacy network. The organising problem was immediately recognisable: steer capable devices toward the preferred band without abandoning clients that still needed another route.

At NANOG 69 in 2017, the public menu had two SSIDs: a protected 802.1X service on 2.4 and 5 GHz and an open legacy service. The notice described the conference network as geared for high availability and the demonstration of industry best practices. A 2019 notice retained the same broad protected-versus-legacy structure.

Those claims should be read with precision. “Geared for” describes intent. “High availability” and “best practices” sound like performance and design conclusions, but the attendee page did not attach thresholds, failure tests, client denominators or incident results. The statement is valuable evidence of what NANOG wanted the network to represent. It is not an independent measurement of what the network delivered.

By NANOG 86 in October 2022, the third choice was visible: an IPv6-only SSID alongside the protected main network and open legacy access. The NANOG 87 notice repeated the arrangement, with 802.1X on the main network and an engineering email address for questions.

June 2023 brought a more revealing transition. The NANOG 88 instructions said NANOG would no longer use 802.1X encryption for the main SSID and had moved to a WPA3 pre-shared key. The main option spanned 2.4, 5 and 6 GHz. The notice retained open legacy and IPv6-only networks and added an OWE option intended to encrypt supported clients while leaving others unencrypted.

The OWE line matters precisely because it did not remain visible in the later notices reviewed here. It shows that the public menu can change and that one event’s design should not be projected forward as a permanent policy. By NANOG 89, the repeated form was the three-choice menu: main WPA3/PSK, open legacy and open IPv6-only. A historical SSID name is not a current guarantee.

Repetition creates a policy surface

The NANOG 89 notice names AT&T for connectivity, Cisco Meraki for wireless and Juniper Networks for edge routing. Its detailed description says the IPv6-only subnet has no IPv4 gateway or DHCP server. The NANOG 90 notice keeps the three SSIDs but changes the connectivity credit to Charter Communications. Cisco Meraki and Juniper retain their labelled wireless and edge roles.

At NANOG 91, Washtenaw Fiber is credited for connectivity, while Cisco Meraki and Juniper again appear for wireless and edge routing. The NANOG 93 welcome message repeats the three choices and directs questions to [email protected]. The NANOG 94 instructions, preserved on the attendee archive, credit AT&T and HPE Juniper Networks and use the same access menu.

The NANOG 95/ARIN messages add the co-located organisations to the SSID names—NANOG-ARIN, NANOG-ARIN-Legacy, NANOG-ARIN-V6 Only—while preserving the three functions. The name is evidence of a co-branded access surface, not proof that ARIN designed, owned or operated it. By NANOG 97, the names return to NANOG alone and the connectivity provider changes to Ziply Fiber.

This sequence establishes two things. First, the access design is more stable than the contributor roster. Second, NANOG makes at least some division of labour visible: connectivity, wireless and edge routing are named separately where the notice supplies all three. That is useful operational literacy. It discourages the fiction that “the network” is one undifferentiated entity delivered by one actor.

It does not disclose a control map. A sponsor credit does not reveal the contract, staffing plan, equipment custody, venue dependency, escalation chain, acceptance criteria or liability allocation. “Edge routing” might describe equipment, engineering labour, service support or a combination; the public label does not say. “Connectivity” does not establish path diversity, physical route independence or failover. “Wireless” does not tell a reader who configured the controller, watched the spectrum or closed incidents.

The correct conclusion is not that responsibility is absent. It is that contribution is labelled more clearly than accountability.

A shared key is protection, not identity

The main SSID’s public credential is deliberately easy to distribute. That is sensible at a conference: hundreds of attendees need access quickly, and the password appears in messages that may be archived. The resulting protection should not be misdescribed.

The notice supports a bounded claim: the main network uses WPA3 with a pre-shared key. It does not support a claim that every attendee has an individual credential, that devices are attributable to named people, or that all traffic is safe from every observer. Nor does it establish which WPA3 mode, client isolation or management-frame settings operated at a specific meeting unless another source supplies those facts.

The legacy network is described more bluntly: open and unencrypted. That is a useful warning, not a verdict on every application. Modern applications may add their own transport encryption, while other traffic may remain exposed. The event notice does not inventory attendee applications, endpoint hygiene or threats. It is therefore more accurate to say the legacy SSID removes link-layer encryption than to declare the entire user session either safe or unsafe.

Compatibility has value. A person may carry a device that cannot negotiate the preferred mode, may need to test old equipment or may be troubleshooting a problem where an open association helps isolate the fault. Removing the legacy route could improve one dimension of the default posture while excluding devices for reasons unrelated to operator competence. Keeping it creates a duty to label it accurately and, ideally, to measure whether the fallback remains necessary.

That last denominator is missing from the reviewed record. The notices do not say how many clients tried the legacy network, why they did so, whether they later moved to the main SSID or how many failures were caused by authentication rather than radio coverage or application behaviour. Without those numbers, “legacy” is a compatibility promise, not evidence of compatibility demand.

IPv6-only: a test surface, not a success statistic

The IPv6-only SSID is the most intellectually attractive of the three. NANOG is an operators’ meeting; placing a protocol constraint in front of attendees can expose assumptions that a slide deck never reaches. A laptop or application that silently depends on IPv4 may fail where a dual-stack network would hide the dependency. A service that works natively over IPv6 can reveal a cleaner path.

But the label establishes less than its symbolism suggests. The detailed NANOG notices say there is no IPv4 gateway or DHCP server. They do not say whether the network provides NAT64, DNS64, 464XLAT support or another bridge to IPv4-only destinations. They do not say whether an RFC 8925 IPv6-Only Preferred mechanism is in use. They do not publish resolver behaviour, prefixes, translation capacity or application test results.

The technical difference is consequential. RFC 8925 explains an IPv6-only preferred mode in which capable hosts may forgo an IPv4 address, typically with a network service that can reach IPv4-only destinations. RFC 8683 discusses NAT64, DNS64 and 464XLAT deployment choices for operator and enterprise networks. Neither document proves that NANOG used any of those functions. They show why “no IPv4/DHCP” is not a complete reachability description.

This is an important reporting restraint. The presence of an IPv6-only SSID is real operational evidence: NANOG advertised an access network that constrained the client side. It is not adoption evidence. The archive supplies no count of associations, successful sessions, protocol mix, failed applications or users who switched back. It cannot establish that a clinic changed attendee behaviour or that an operator later deployed IPv6 at work.

The separate NANOG 93 IPv6 Clinic illustrates the boundary. The clinic offered presentations, a hands-on workshop and whiteboarding. That is evidence of teaching activity. The meeting SSID is evidence of an access choice. One does not measure the other. A workshop registration does not prove the production Wi-Fi worked; a working connection would not prove a lesson caused later deployment.

A short operational note could close the useful part of this gap without identifying users. It could state the intended reachability model, count aggregate associations or leases by SSID, report broad failure categories and say whether the IPv6-only service remained available for the planned window. That would turn an attractive label into a reproducible test surface.

The archive is split across surfaces

NANOG’s public record is not one page. Welcome emails hold details that permanent event pages may not preserve. The NANOG 93 meeting-stats page reports 702 in-person attendees and displays the main WPA3 SSID plus a help address. In the reviewed version, it does not display the legacy and IPv6-only options described in the attendee welcome message.

This is not necessarily an error. A stats page may be designed to show selected highlights rather than reproduce every instruction. It does create an evidentiary trap. A later researcher using only the permanent page could conclude that NANOG 93 had one published SSID. The mailing-list record shows three. Conversely, the 702-person attendance figure cannot be used as the denominator for any wireless adoption rate because people are not devices, and no SSID-specific client count is published there.

The same separation affects support. Multiple notices give [email protected]; NANOG 97 directs attendees to a support address. This is a real escalation entry point. It does not reveal coverage hours, response targets, ticket volume, severity, root cause, resolution or closure. An inbox is not an incident record, just as a network name is not an availability measure.

Archive design therefore becomes part of operational accountability. The most useful artifact would not be a larger permanent marketing page. It would be a stable, versioned link from the event page to the exact welcome notice and a compact after-action record. That link would preserve what was offered; the after-action note would state what was delivered.

What a short after-action record should contain

The record need not resemble a carrier audit. Eight fields would materially improve what an attendee and future engineer can verify.

Service window. Publish planned start and stop times and whether the three SSIDs remained available for that window. Avoid converting partial monitoring into a blanket uptime percentage.

Role matrix. Name the organisation responsible for Internet connectivity, wireless, edge routing, venue handoff and NANOG support, using the same restrained labels as the attendee notice. If responsibility was shared, say so. A contribution need not be portrayed as exclusive operational control.

Access denominators. Report aggregate associations, leases or sessions by SSID with a clear definition. Do not call MAC addresses people or attendees, and explain whether randomisation or retries may inflate counts.

IPv6 reachability model. State whether the IPv6-only SSID was native-only or offered a named translation mechanism to IPv4-only destinations. Report the answer as design, not as proof that every application worked.

Material incidents. Give start and end intervals, affected surface, broad symptom and corrective action for failures above a published threshold. Minor client-specific problems can be counted without exposing individual tickets.

Support aggregate. Publish the number of network requests, broad categories and median or banded time to first response and closure. Empty fields should remain unknown, not be rendered as zero.

Telemetry and retention. State, at a category level, whether association, DHCP, DNS, flow or security telemetry was collected, for what purpose, who could access it and when it was deleted or de-identified. Do not publish the data itself.

Teardown. Confirm that temporary credentials, configurations, sponsor access and retained logs were handled under the stated post-event process. A one-line confirmation with an accountable role is more valuable than a decorative claim of ephemerality.

This design deliberately avoids raw packet captures, device identifiers, client histories, credentials, private contracts and exploit-relevant diagrams. Accountability does not require turning a short-lived network into a surveillance archive or a target catalogue.

The strongest case for the current level of disclosure

The strongest objection is proportionality. NANOG builds a network for a three-day event across changing hotels, radio conditions, providers and unmanaged devices. Its first duty may be to connect people and resolve problems, not to produce a publication after every meeting. Engineers already expose a support address. The three-SSID menu is unusually explicit compared with ordinary conference Wi-Fi. Detailed topology and security information could help attackers. Client statistics can become personal data when the population is small or the fields are granular.

That defence has force. A demand for every configuration, alert and ticket would be counterproductive. It would consume volunteer or staff time, chill candid incident handling and create new privacy and security risk. A network can be responsibly operated without publishing its internal control plane.

The answer is to report at the scale of the public promise. NANOG already tells attendees which access modes exist and credits named provider roles. A short aggregate note would test those statements without exposing how to attack the system. It could be produced from the same operational handoff used to close the event. If a field is not measured, the note can say so rather than invent precision.

The historical record suggests that these questions are not foreign to NANOG. Steering Committee minutes from 2007 record concern about an alternative path if a planned 10G “demonstrator” path failed, identify contracted wireless work and describe an XKL display about the meeting network. The minutes prove that path resilience, role allocation and demonstration value were discussed for NANOG 40. They do not prove anything about NANOG 97’s delivered topology.

That is exactly the evidentiary discipline an after-action note should preserve: plan is not delivery; contribution is not control; route diversity is not established by two names; a demonstration is not an outcome.

Measure the choice, not the person

The obvious objection to per-SSID counts is privacy. At a small event, a timestamp, device identifier and network choice can become a behavioural trail. An engineer using IPv6-only at 02:00, reporting a particular application failure and then moving to Legacy may be recognisable to colleagues even if a name is removed. A useful report must therefore be designed from the aggregate backwards, not produced by publishing a sanitised copy of operational logs.

The first protection is a narrow purpose. The proposed counts answer whether each advertised access mode was used and where broad failure concentrated. They do not answer who used it, which sites they visited, which DNS names they resolved or what employer owned the device. The second protection is time aggregation. A meeting-wide total or coarse daily band is usually enough; minute-by-minute series add re-identification risk without improving the governance question.

The third protection is categorical incident reporting. “Authentication incompatibility,” “radio coverage,” “IPv6 application reachability” and “venue handoff” can expose where responsibility sat without preserving an individual complaint. Rare categories may need to be merged or withheld. A zero should appear only when the system actually measured the field and observed none. Otherwise the value is unknown.

This approach also disciplines operations. If the team cannot define whether it is counting associations, DHCP leases, devices or sessions, a large number has no stable meaning. If MAC randomisation causes one device to appear several times, the report should say so. If open IPv6-only has no DHCPv4 by design, a DHCPv4 lease count is not a service denominator. Measurement begins by choosing a unit that corresponds to the promise.

The same discipline applies to privacy. A declaration that logs were “deleted after the meeting” is not meaningful unless the data categories, copies and responsible actor are bounded. Network gear, cloud dashboards, help-desk mailboxes and provider systems may have different retention. The public note need not list every internal path, but it can say which categories NANOG controlled, which were handled by a provider, and which retention statement applies to each.

Teardown is part of service, not an administrative epilogue. A shared password printed in an archive remains public forever; the protection comes from ending the network or changing the credential, not from later secrecy. Temporary provider accounts, controller access and stored configurations likewise have a life after the last session. A confirmed close-out is the final control in the access contract.

What “high availability” could mean for three days

The phrase does not need a carrier-grade formula to become testable. For a meeting network, availability could be stated against the scheduled service window and separated by control surface. The wireless SSID might remain visible while upstream connectivity fails. The Internet path might work while authentication fails. IPv6-native destinations might remain reachable while any intended translation service is impaired. One headline percentage would hide these distinctions.

A compact report could therefore distinguish at least association, address configuration, DNS, Internet reachability and support. These are not a complete protocol model, but they align with what an attendee experiences. A material-incident threshold might combine duration and affected scope: for example, a failure lasting beyond a stated interval or affecting more than one room or one access mode. NANOG could choose a different threshold; the important point is that the threshold exists before the summary is written.

Failover deserves its own language. A notice that credits a connectivity provider does not claim two paths. If two upstreams or circuits exist, the report should distinguish planned redundancy, physical independence as represented by providers, and an observed or tested switchover. Two logical sessions over one physical route do not establish the same resilience as diverse facilities. Conversely, withholding a fibre map for security reasons does not prevent NANOG from saying whether the planned protection was tested and whether it met the acceptance criterion.

Acceptance should be separated from incident response. A pre-opening checklist can verify SSID advertisement, association, address assignment, resolver behaviour, representative destinations and the intended IPv6 model. It cannot guarantee the experience under peak load. The after-action note can state that the checklist passed, then report what changed when hundreds of unmanaged devices entered the venue. Both facts matter; neither cancels the other.

The network’s brevity makes this more, not less, useful. A permanent operator can accumulate monthly trends. A conference gets one short observation window before the infrastructure disappears. Without a frozen summary, knowledge remains in mailboxes and individual memory, and the next venue may repeat a solved problem. The purpose is operational continuity across changing contributors, not a public scorecard designed to shame them.

Compatibility should have an exit test

Legacy access is easy to retain indefinitely because its absence creates immediate complaints while its presence distributes risk quietly. A measurement framework can avoid that asymmetry. NANOG need not announce that Legacy will disappear. It can publish the share of defined connection attempts, the main failure categories that led users there and whether those failures were remediable in the preferred network.

If Legacy remains heavily used because a material class of devices cannot join WPA3, that is evidence for retaining it and improving warnings or client isolation. If use is negligible and the few cases are test devices, NANOG can consider making access available on request rather than continuously. If users select it merely because its name appears easier, clearer copy may move them to the protected default.

The same exit-test logic applies to a one-meeting feature such as OWE. The June 2023 notice proves it was offered; later silence cannot tell us whether it failed, was unnecessary, was folded into another design or simply stopped being mentioned. A small decision note—continue, modify, retire, with an aggregate reason—would prevent archive readers from inventing a technical verdict.

An exit test is not hostility to compatibility. It is how compatibility avoids becoming a permanent, unexamined exception. The burden should remain proportionate: one paragraph and a few aggregates, not a formal standards process.

Three duties, not three verdicts

The main network creates a duty to describe protection without overstating identity or end-to-end safety. The legacy network creates a duty to label the absence of link-layer encryption and to test whether the fallback is still operationally needed. The IPv6-only network creates a duty to say what “only” means for reachability and to report aggregate success and failure without converting users into a public dataset.

Across all three, NANOG has a fourth responsibility: preserve actor boundaries. AT&T, Charter Communications, Washtenaw Fiber and Ziply Fiber appear at different meetings as connectivity contributors. Cisco Meraki, Juniper and HPE appear in wireless or edge roles. Those credits make the temporary network legible, but they do not assign every operational act or consequence. A provider roster should lead to a role matrix, not to a story in which sponsors collectively become “the operator.”

The reviewed record supports a balanced conclusion. NANOG has done something concrete and repeatable: it gives attendees an explicit choice among a protected default, an open compatibility path and an IPv6-only test surface, and it has preserved much of that choice history in public notices. That is more informative than a single hotel SSID and more honest than hiding protocol trade-offs.

The same record cannot show whether the promise worked. It contains no regular per-meeting denominators for associations, success, availability, incidents, support or teardown, and it does not describe the IPv6 path to IPv4-only services. Those are limits of public evidence, not proof of weak engineering or absent internal controls.

NANOG does not need to publish its network. It needs to publish the result at the same level of abstraction as the choice it asks attendees to make. Three SSIDs already state three duties. A short, privacy-preserving operational note would show whether those duties survived contact with the room.

Sources