nog.fi meeting 2026.06#

Core#

RFC8950 for a V4LESS(-AS) World: Diving into the magic of IPv4-with-IPv6 Next-Hops#

Abstract Recording

Daniel Wagner (DE-CIX), Tobias Fiebig (TU Wien)

• Why: The most directly relevant fabric/interconnect talk on the program. Carrying IPv4 routes with IPv6 next-hops dissolves several standing design pains in both IXP peering LANs and large ECMP fabrics — exactly the DC/WAN interconnect territory this PM works in.
• What: A working walkthrough of what IPv4-with-IPv6 next-hops (RFC 8950, which extends RFC 5549-style extended next-hop encoding to eBGP) enables: IXPs without IPv4 peering-LAN growth pain, seamless IPv4 routing at /32 granularity, IPv4-free transport links, a fully ARP-free infrastructure, and ECMP-enabled L3 underlays for 100G+ fabrics without LACP. Includes an open invitation to peer with V4LESS-AS (AS215250), their live RFC 8950 testbed at an internet exchange.
• How: IPv4 NLRI is advertised over BGP sessions using IPv6 next-hops, so the entire L3 core — peering LANs, transport, fabric underlay — can be IPv6-only while still serving IPv4 destinations; with no IPv4 at L2/L3, ARP disappears and routed ECMP replaces LACP-bundled L2 links.
• Where applicable: A standards-based technique, not vendor- or org-specific in principle. Constraints: every router on the path must support extended next-hop encoding, and the ARP-free/no-LACP benefits are easiest to realize in greenfield or single-administrator fabrics. The V4LESS-AS testbed (AS215250) is the concrete proof point.

ASPA - RPKI BGP Path Verification#

Abstract Recording

Tim Bruijnzeels (RIPE NCC)

• Why: RPKI today only validates route origin; ASPA is the next mechanism, validating AS paths and rejecting route leaks. Anyone responsible for BGP security needs to know where this stands operationally.
• What: A walkthrough of the ASPA object type and its verification algorithm, how to sign provider authorizations in the RIPE NCC RPKI Dashboard, how validation behaves in practice, and real uptake and lessons learned so far. (from abstract only)
• How: AS holders publish an ASPA object authorizing their upstream providers; validators use it to check received paths for customer→provider consistency, detecting and rejecting "valleys" — leaked paths — in addition to origin validation.
• Where applicable: General BGP technique, not org-specific. Requires RPKI CA participation and validator support on receiving routers; protection only materializes as transit providers adopt it, which makes the uptake discussion the key operational caveat.

The IRR Landscape and its Implications on Global Internet Traffic#

Abstract Slides Recording

Daniel Wagner (DE-CIX)

• Why: Route-server prefix filters at IXPs are generated from IRR data; when AS-SETs are inconsistent or stale, traffic that should flow through the peering fabric doesn't. This is the data-quality counterpart to the ASPA talk, attacking the same trust gap from the legacy side.
• What: Latest results from Wagner's RIPE Labs article series on the IRR landscape, including previously unreleased insights on AS-SET heterogeneity, IRR lookup ordering, and the measured traffic impact at a very large IXP, ending in a community call to action. (from abstract only)
• How: Analysis of IRR database contents and route-server filter-generation behavior, correlated with observed traffic at a large IXP.
• Where applicable: The measurement is DE-CIX-scale (org-specific), but the mechanism — filters generated from heterogeneous IRR data — applies to every IXP participant and most transit relationships. Direction of findings transfers; absolute numbers do not.

A deep-dive into NLNOGs tools#

Abstract Recording

Nick Bouwhuis (NLNOG)

• Why: Free, community-maintained, vendor-neutral tooling that operator teams can adopt immediately — the highest transferability-per-effort item on the program.
• What: A tour of NLNOG's operator tools — the RING (shared shell access across member networks) and IRRexplorer (IRR/RPKI cross-checking), among others — what each is useful for, and the maintenance challenges of running community infrastructure. (from abstract only)
• How: RING members contribute a node and in return get shell-level vantage points across other member networks for debugging from outside their own AS; IRRexplorer aggregates IRR and RPKI data to check consistency of route objects and ROAs.
• Where applicable: Open to any operator willing to participate (contribute a node); no vendor dependency; broadly applicable across scales. The maintenance-challenges portion is useful for anyone considering similar shared tooling.

Knowledge is the power - Network Automation beyond the vendor#

Abstract Recording

Amin Hamidi Younessi (Reonel Oy)

• Why: Demonstrates that vendor-portable automation is achievable with plain Python and native APIs — a counterpoint to framework lock-in, relevant to anyone running mixed estates or setting automation strategy.
• What: One Python skillset — querying live state, provisioning BGP peers, pushing wide config changes — applied across MikroTik RouterOS and Cisco IOS-XE via their native APIs, demonstrated on a real ISP/IXP lab built on EVE-NG. No Ansible, no heavy frameworks: HTTP, JSON, and a few dozen readable lines of Python. (from abstract only)
• How: Direct API calls against each vendor's native interface, with the protocol (BGP) as the stable abstraction — "when you understand the protocol underneath, the vendor becomes just a detail."
• Where applicable: General technique, but the demo is lab-based (EVE-NG) and covers exactly two vendors, so expect small adapters per platform. Most practical for small/mid-size operators; not a scale-out automation architecture.

The No-Nonsense Approach to Build Infrastructure that Lasts#

Abstract Recording

Tony O'Sullivan (RETN)

• Why: Physical-infrastructure resilience — cable cuts, geopolitical and climate shocks — is core WAN territory for this PM, and this is a hard-won experience report from a network that stayed online through events that took others down.
• What: An experience talk (the deck is titled "Hardwired for Chaos") on how RETN (AS9002) has scaled a lean, 44-country network and kept it running "under fire, literally," challenging the industry to build infrastructure that is innovative, scalable, and sustainable.
• How: The abstract gives principles rather than mechanism — expect lessons on physical/route diversity, lean operations, and surviving cable cuts rather than a technical deep dive.
• Where applicable: RETN-specific scale and geography (pan-Eurasian footprint with distinct geopolitical exposure). The resilience lessons transfer; the specific operating model and cost base do not.

Managing Cryptographic Transitions: Crypto‑Agility as an Enabler and a Challenge#

Abstract Recording

Markus Rautell (VTT)

• Why: PQC migration will land squarely on identity and network-security infrastructure — passkey, token, and certificate stacks all need swappable primitives. This talk frames the architectural problem that precedes any migration plan.
• What: A position talk: cryptographic primitives offer temporary rather than permanent protection, PQC transition timelines are external and time-critical, and system architectures are still widely designed so that cryptographic updates are risky, slow, and resource-intensive; crypto-agility is hard but the work must continue. (from abstract only)
• How: Architectural/design discussion rather than a specific mechanism — the abstract offers no concrete technique.
• Where applicable: Broadly applicable to any system with long-lived cryptographic dependencies (identity, DNSSEC, TLS, control-plane protocols). Conceptual rather than deployable — treat it as framing for migration planning, from a research organization's perspective.

Adjacent#

(Why) GPUs are awful (to virtualize)#

Abstract Recording

Johannes Brummer

• Why: For anyone running networks for AI-era compute, knowing why GPUs are painful to virtualize (device assignment, passthrough, memory mapping) shapes what the fabric must support — SR-IOV/passthrough choices interact directly with RDMA fabrics.
• What: Hands-on experience virtualizing different GPU types on multiple different hardware platforms, plus approaches to providing them to actually paying customers. (from abstract only)
• How: Practical experience report; no methodology stated in the abstract.
• Where applicable: Hosting/service providers offering GPU compute. Useful context for designing networks under GPU clusters, but it is a compute virtualization talk, not a networking one.

Root KSK Rollover 2026: An Operator's Readiness Checklist#

Abstract Recording

Roy Arends (ICANN)

• Why: October 2026 brings the first root KSK rollover since 2018; validating resolvers with badly managed trust anchors are the ones that break. This is a concrete, adoptable checklist — exactly the kind of ops content worth taking away.
• What: A minutes-long readiness checklist for validating-resolver operators: verify resolvers use managed trust anchors, confirm the active root KSK, and inspect RFC 5011 state — with concrete commands and expected outputs for common resolver software, designed to slot into existing workflows. (from abstract only)
• How: Relies on RFC 5011 automated trust-anchor updates (or RFC 9718 operation); the checklist catches hardcoded/static trust-anchor configurations before they break.
• Where applicable: Any operator of validating recursive resolvers, regardless of scale. Should be routine if trust anchors are already managed correctly.

About localroot#

Abstract Recording

Roy Arends (ICANN)

• Why: Serving a local copy of the root zone in resolvers is a recurring resilience-vs-correctness debate; an unbiased treatment of both sides is rare and useful.
• What: A 5-minute lightning talk laying out the pros and cons of locally hosting the root zone in your resolver. (from abstract only)
• How: Short tradeoff discussion; details not in the abstract.
• Where applicable: Recursive-resolver operators weighing elimination of root-server queries against staleness and consistency risks.

Digital Networks Act and fair share update#

Abstract Recording

Klaus Nieminen (Traficom)

• Why: EU regulation will reshape interconnection economics — directly relevant context for anyone whose products touch EU peering and transit markets.
• What: A regulator's update on the EC's "complex voluntary conciliation" on fair share — the deck frames it as "From Fair Share to Ecosystem Cooperation: how the EC's DNA proposal plans to reshape IP interconnections" — with the outcome still undecided among the co-legislators.
• How: Policy talk, not technical; explicitly tentative about where the discussions will end.
• Where applicable: EU-operating networks, IXPs, and content delivery players. Finnish-regulator (Traficom) perspective on an EU-wide process still under debate.

NAF Framework#

Abstract Recording

Jaakko Rautanen

• Why: A shared vocabulary for network automation systems helps compare tools, architectures, and roadmaps — directly useful to a PM defining automation product strategy.
• What: A 5-minute introduction to NAF, a community-driven effort that helps understand network automation systems by giving them shared vocabulary. (from abstract only)
• How: Not detailed in the abstract — expect taxonomy and concepts rather than a runnable artifact.
• Where applicable: Anyone building, buying, or comparing network automation. Early-stage community effort; judge maturity accordingly.

Wildcard#

Veeam MCP server#

Abstract Slides Recording

Janne Haatainen (Veeam)

• Why: Not about networking at all, but a signal of where ops tooling is heading: local AI agents acting on infrastructure products through MCP — the same wave that will demand identity and authorization models for agents.
• What: A quick, sponsored lightning talk introducing a Veeam MCP server that lets local AI interact with Veeam products (the materials reference a Claude-based setup).
• How: An MCP server exposing product operations to a local LLM client — the pattern, not the product, is the takeaway.
• Where applicable: Veeam estates specifically; flag it as a sponsor slot. The generalizable signal is the MCP-ification of infrastructure tooling, which sits interestingly next to questions of identity and authorization for AI agents.

Themes#

• Path-wide routing security is arriving: ASPA moves RPKI beyond origin validation while the IRR-landscape work shows the legacy filter-generation stack measurably constraining traffic — two talks attacking the same interdomain trust gap from opposite sides.
• IPv6 as the universal substrate: RFC 8950 next-hops turn IPv6 into the transport for IPv4 service — ARP-free cores, IPv4-free links, ECMP L3 fabrics without LACP. IPv4-over-IPv6 is shifting from lab trick to operating model.
• Portable automation and community tooling over vendor lock-in: NLNOG's shared tools, vendor-neutral Python against native APIs, and the NAF vocabulary effort all push the same direction — skills and community infrastructure that outlive any vendor choice.
• Cryptographic lifecycle as routine operations: the root KSK rollover checklist and the PQC crypto-agility talk both put key and primitive transitions on the ops calendar rather than the research agenda.
• Physical resilience under stress: a 44-country network kept online through literal fire and cable cuts anchors the program's physical-infrastructure thread; the local-root DNS debate echoes the same resilience instinct at the resolver layer.
• AI on both ends of the wire: selling GPU compute (and its virtualization pain) on the demand side, and MCP-driven local AI agents operating backup products on the ops side.