Turn IPv6 Training into Work Your Team Can Demonstrate
Completing an IPv6 course does not, by itself, show that a team can make a safe change to its own network. That requires relevant knowledge, a representative test environment and results another engineer can inspect. This guide proposes role assignments, lab tasks and pilot acceptance criteria for applying knowledge gained through RIPE NCC resources. Adapt the internal programme to the selected course’s published scope, your team’s access and the infrastructure it operates.
Use the RIPE NCC IPv6 course and certification selection guide to compare courses, prerequisites and certification. Here, the question is what happens after that choice: who performs which task, in which environment, and how will they demonstrate a correct result? Aim for a reviewed address plan, test record and operating procedure as well as a record of participation.
1. Match Each Role to a Knowledge Gap and Deliverable
Start with a short discussion and sample task to assess experience. Reading an IPv6 address, explaining the boundary of a routed customer prefix and locating the layer responsible for a failed HTTPS request are different skills. Select learning according to the decisions each person will make, rather than requiring everyone to follow an identical course sequence.
| Role | Internal exercise | Reviewable output |
|---|---|---|
| Network engineer or architect | Explain addressing, routing and provider boundaries | Prefix inventory, topology and route/filter review |
| System administrator or DevOps engineer | Test the OS, DNS, web service and application dependencies over both protocols | Versioned configuration notes and application test results |
| Security owner | Evaluate IPv6 access policy, control messages and logging | Results for permitted and prohibited traffic |
| Support or NOC | Distinguish DNS, routing, TLS and application failures | A sample incident, diagnostic steps and an escalation handoff |
| Technical lead or product manager | Define scope, resources, customer impact and decision authority | Measurable goals, dependencies and a pilot continue/stop decision |
One person may fill several roles in a small team. Where possible, separate the person preparing a change from the person reviewing its results. If a provider controls a layer, document which evidence the team can request rather than assuming it can change that layer. A site team using shared hosting has different learning needs from an operator managing its own ASN and BGP policy.
Separate Course Knowledge from Local Configuration Work
IPv6 Fundamentals covers addressing and deployment concepts; it explicitly excludes configuring routers, servers and other devices. Supplement Linux, Windows, network-device, container or Kubernetes tasks with documentation for the actual product version. The in-person IPv6 Advanced course requires participation in the Fundamentals training course or its e-learning course as well as the stated technical knowledge. IPv6 Security is intended for participants with experience running an IPv6 network. These conditions were checked on 4 November 2026; read the current requirements for the particular format you choose.
2. Prepare the Test Scope and Responsibilities Before Training
Select a small service and a specific learning objective. For example, a test website might need to complete the same HTTPS operation over IPv4 and IPv6. A deadline such as “migrate the entire data centre in six months” is not an acceptance criterion without an inventory and dependency analysis. First identify the users that still require IPv4, the components that support IPv6 and the access path that will change.
- Record the provider’s IPv6 assignment, on-link or routed-prefix model and reverse-DNS owner.
- Inventory routers, switches, firewalls, virtualisation, operating systems and application versions.
- Identify DNS, CDN, load-balancer, API, mail and management-access dependencies.
- Define change authority, the test window, observation tools and rollback responsibility.
The discussion of IPv4 exhaustion and hosting cost planning can support the business case; it does not establish that IPv6 will always reduce total cost. Consider address costs, training time, the test environment and the work of operating two protocols separately. Teams managing their own Internet number resources should check current registry policies. A customer configuring one VPS does not automatically need to perform LIR administration.
Distinguish Lab Resources from Production Access
Prepare an environment with clearly identified test addresses, domains and accounts. If you use VLANs or another isolation mechanism, also verify management access and any path into production; calling an environment a lab does not establish isolation. Use synthetic data when the task does not require customer information, and define access and retention rules for collected logs.
If you are considering a VPS or dedicated server, confirm IPv6 availability, assignment size and management permissions for the selected service. Do not assume that the lab permits changes to provider BGP, access-switch security or customer-prefix delegation. For layers outside the team’s control, a documented topology, configuration review or provider-supplied confirmation can be an appropriate deliverable.
3. Define a Lab Task for Each Learning Objective
Address Planning and Assignment Boundaries
Ask the network participant to distinguish the organisation’s available blocks, customer prefixes, link subnets and individual addresses. A /32 or /29 allocation can illustrate regional, data-centre and service divisions only if the organisation actually has such space available. Include racks, hypervisor clusters and VLAN boundaries in the example topology. Document growth reserves, overlaps and ownership. A hierarchical plan can reduce avoidable renumbering without eliminating every future reason to renumber.
An IPv6 address is 128 bits. A /64 subnet on an ordinary Ethernet LAN using SLAAC is not a separate routed allocation for each interface. A customer /48 or /56 can contain multiple subnets; requirements and provider policy determine the assignment. Inter-router point-to-point /127 prefixes and /128 host routes have different scopes. The reviewer should check those distinctions and confirm that the plan remains within the available allocation. RFC 6177 does not prescribe one universal assignment size for every end site.
Ask the participant to read and write compressed address notation and distinguish global unicast, link-local and ULA addresses in the plan. Check that the IPAM record and device configuration agree on the prefix and its owner. If server templates, a customer panel or automation assign addresses, test those layers against the same assignment model. Verify address assignment and DNS updates together in the provisioning workflow, including a record of a failed operation.
Routing and Network Paths
A team operating its own routing can use a test topology for static routes or the OSPFv3, IS-IS and BGP scenarios relevant to its role. Prepare a record explaining which prefixes import/export filters allow, the return path when multiple upstreams exist and the expected failure behaviour. BGP communities and peering decisions must match the actual policy. A course example should not be copied directly onto a production router.
A RIPE Database route6 object and an RPKI ROA serve different purposes. A ROA authorises an AS to originate specified prefixes; it does not validate the entire AS path or guarantee application reachability. For a system team using provider-managed routing, the useful task may instead be to document the guest address, gateway, connectivity results and evidence needed by the provider.
DNS, Web and Application Access
A system administrator can prepare a test service using the Linux VPS static IPv6 guide, matched to the OS version and provider model. Distinguish static Linux interface configuration from RA/DHCPv6 according to the provider model. Examine the IPv6 listener in Nginx, Apache or the deployed web server together with A/AAAA records, firewall policy, the TLS hostname and application response. Successful ping does not establish a successful HTTPS operation. Record separate IPv4 and IPv6 results for the same target and operation. The OS’s IPv6 ping and traceroute options can help inspect the network path; complete them with application tests. With anycast, a load balancer or a CDN, record which endpoint and path the measurement describes.
Reaching an authoritative DNS server over IPv6 and adding an AAAA record to a domain are different checks. Review name-server addresses required by the delegation and any relevant AAAA glue separately from the website’s AAAA record. Test the recursive resolvers and forwarders you operate over the intended address family. Verify IPv6 reverse DNS under ip6.arpa with the responsible party. An MX record names a mail server rather than containing an IP address directly. Inspect code using literal IPv4 addresses, external APIs, CI/CD agents and management tools as part of the dependency review. With a CDN or reverse proxy, distinguish the client-facing endpoint from the origin’s access path.
The IPv6-only and dual-stack hosting comparison can help select the model to test. Ordinary NAT64/DNS64 supports an IPv6 client reaching an IPv4 destination; it does not automatically let IPv4 visitors reach an IPv6-only website. That incoming path needs a suitable separate front end or another supported design. Enabling IPv6 is not, by itself, a promise of higher search rankings or faster service.
The IPv6-only VPS and NAT64/DNS64 guide provides further context for separating client egress from a website’s incoming IPv4 path. Select the scenario that matches the lab topology rather than treating the two directions as interchangeable.
Treat Mail as a Separate Application Exercise
Passing a web test does not establish mail delivery. Use the guide to email over IPv6, reverse DNS and SPF to support an authorized test arrangement. Review the actual sending IPv6 address, forward/reverse DNS, server hostname and SPF authorization. Check DKIM signing and DMARC alignment separately; changing IP transport alone does not require changing all those records.
Record the test recipient, time, SMTP reply and message identifier where available. Acceptance by the recipient server does not prove inbox placement. If policy or reputation causes rejection, completing network training is not a delivery guarantee. Give the mail exercise its own owner and acceptance criterion rather than treating it as an automatic consequence of the web pilot. The guide to IPv6 delivery checks with PTR, HELO, SPF and blocklists can support that separate review.
Security, Control Messages and Logs
The security participant should apply equivalent access intent across IPv4 and IPv6 while respecting protocol-specific requirements. Blocking all ICMPv6 can disrupt neighbour discovery and the Packet Too Big messages needed for Path MTU Discovery. Evaluate RA-Guard, DHCPv6 security and NDP risks according to the relevant link, switch permissions and topology. Copying the same rule list to every server does not constitute a useful policy test.
Compare a permitted application flow and a prohibited connection in the isolated environment. Verify that records preserve the IPv6 address, timestamp and incident context. Privacy addresses or different client addresses do not, on their own, identify one person conclusively. Where applicable, test IPv6 event handling in the IDS/IPS and log-collection pipeline. Ask support to use those records to prepare a short procedure separating DNS, routing, TLS, MTU and application failures.
For a VPS firewall exercise, the nftables configuration guide with IPv6 rules can provide additional examples. Match the examples to the actual host and network policy, then review the permitted and prohibited flows in the lab.
4. Collect Reviewable Evidence Instead of a General “Works” Result
Each task should record its target, environment/version, expected behaviour, observed result and reviewer. Include a controlled failure case so the team can assess whether monitoring and diagnosis identify the right layer. Do not create these failures on a shared production service just to produce evidence for a training exercise.
| Task | Example acceptance evidence | Insufficient by itself |
|---|---|---|
| Address plan | A second person checks allocation boundaries and subnets | An interface displays an IPv6 address |
| Dual-stack web test | The same HTTPS operation returns the expected application response over both families | Ping alone or an IPv4-only check |
| Security policy | The required flow succeeds, the prohibited flow is blocked and relevant logs are present | A saved rule file |
| Monitoring and support | A controlled failure is detected, assigned correctly and followed by a recovery record | A dashboard loads |
| Mail exercise | Sending identity, recipient response and the defined delivery check are reviewed together | A TCP connection or SMTP acceptance treated as an inbox guarantee |
RIPE Atlas offers network measurements from selected probes; record the target, address family, location and time. Complete application validation with your own tests. IPv6 RIPEness uses address-space allocation, route visibility, a route6 object and reverse DNS for its first four preparedness stars, and describes a fifth star based on deployment indicators. It is not evidence of latency or uninterrupted service for one customer’s HTTPS transaction.
5. Base Pilot Progress on Readiness Evidence
Before a pilot begins, review addressing, access policy, monitoring, the support procedure and rollback steps. Choose a limited scope with a named owner. Internal documentation or monitoring can itself be a critical dependency; an internal service is not automatically a low-impact test target. An isolated VPN or management network, selected test VPS or staging site may be suitable; first assess its effect on shared management and observation dependencies. For a customer pilot, establish participation, affected operations and the communication channel beforehand.
- Prepare: Record the current configuration and dependencies, then test observation and recovery paths.
- Verify: Run IPv4 and IPv6 application checks on the chosen service. Publish its AAAA record when the intended IPv6 service is ready and monitored.
- Observe: Compare errors, latency and support records over relevant time windows, using the stop conditions agreed in advance.
- Decide: Expand when acceptance criteria are met. Otherwise reverse the relevant change or return to the lab. Record the outcome and decision owner.
Removing an AAAA record does not immediately clear cached answers. Recovery planning must account for DNS caches and existing connections, retaining working service paths for as long as necessary. Reversing an IPv6-only component also needs a separate design. The dual-stack and AAAA rollout guide covers related deployment checks.
Shared hosting, VPS, mail and internal APIs do not all need to move in one change. Each service can have a different owner and readiness state. Completing one phase does not establish that every later service, or removal of IPv4, is ready. A publicly reachable IPv6 endpoint does not establish that every back-end dependency supports IPv6-only operation. For each new product or region, record the IPv6 requirement, dependencies, test scope and owner. Tell customers what changes, how to test and where to report issues. The training programme should make those dependencies visible and leave the deployment decision with the responsible team.
6. Run the Learning Schedule, Language Support and Review Process
A training coordinator can track access requirements and study time; that role is separate from authority to approve production changes. The current RIPE NCC training overview states that e-learning and webinars are free to everyone with a RIPE NCC Access account, while in-person courses are included in membership. Verify registration, availability, language and prerequisites for the selected event. Certification is a separate process: course participation or success in a local exercise does not automatically earn a badge.
For a team using material in a second language, maintain a shared glossary and internal notes. Ask participants to explain the task to colleagues, while keeping the original course conditions and exam requirements available. Prepare topology questions before a live session and repeat relevant exercises in the lab afterward. This produces a more useful working record than simply repeating the course catalogue.
Alongside completed learning material, track task accuracy, reproducibility, updated runbooks and steps a second person can follow without assistance. For technical outcomes, consider the share of eligible services with IPv6, IPv4/IPv6 connection success, latency, traffic volume and resolution time for related tickets together. The IPv6 adoption and infrastructure discussion provides context; improvements caused by a different client mix or network change should not be attributed solely to training.
Do not set a universal promise of readiness in a few weeks or six months. Existing knowledge, task scope, available staff time and provider dependencies affect the schedule. At each review, distinguish a knowledge gap, a configuration defect and a provider-owned limitation. Another course is not necessarily the remedy for all three.
Update network design documents, change management and incident procedures with the results. A router runbook should reflect routing and filtering policy; a web-server template should cover listeners, DNS and firewall checks; support should separate DNS, routing, TLS and application failures. Record the software version, verification steps and owner of the next review. Maintaining hosting SSL/TLS settings is another task that benefits from the same discipline. End peer-sharing sessions with a reviewed diagram, test record or runbook entry.
For the monitoring exercise, VPS monitoring with Prometheus, Grafana and Uptime Kuma can help select observations and alerts. Match each metric to the network or application behaviour it measures. The IPv6 adoption and infrastructure planning guide offers wider context; decisions still require the team’s own traffic, client mix and dependency evidence.
Open One Concrete Exercise Record
Choose one owner, one test service and one learning objective. Keep the required permissions, documentation versions, success and stop conditions, reviewer and rollback steps in the same record. For example, an exercise using the VPS IPv6 configuration steps is useful when it matches your assignment model and is verified through the application result. Use that evidence to decide on the next learning task or pilot expansion.
