Developinggap named

IPv6

Nikita Tarikin deploys IPv6 on MikroTik RouterOS in production, verified by the MikroTik Certified IPv6 Engineer exam (MTCIPv6E); the customer-facing prefix-delegation path — DHCPv6 Prefix Delegation (DHCPv6-PD) carried over PPP — is the active build-out edge, fully studied and currently delivered through NAT6 rather than through delegated prefixes.

Deployed where it carries production traffic, still in build-out where customer prefix delegation lives — the map below marks which is which.

3.6
Knowledge K̄
2.9
Deployment Ē
46
leaves mapped
23
studied-ahead
3
deployed-ahead

Verified by MTCIPv6E 92%

DEVELOPINGStudy runs ahead of deployment here — the gap is named, not hidden.1Learning2Aware3Confident4Fluent5Teach2.93.6DEPLOYEDIPv6BEDROCKFRONTIER

The map

Every IPv6 leaf the official MikroTik curriculum defines, plotted by what is known against what is run in production. Marks on the diagonal are leaves where the reading and the running reach the same tier; marks that fall below it are the daylight — a part of the protocol understood more deeply than it has yet been deployed. Of every domain on this site, IPv6 carries the widest band of that daylight: more leaves studied ahead of where they run than anywhere else on the map.

K̄ 3.6 Ē 2.9 · 46 leaves · 26 splits1Learning1Learning2Aware2Aware3Confident3Confident4Fluent4Fluent5Teach5Teachno daylight9945KNOWLEDGE →DEPLOYMENT ↑deployed leafknowledge ahead of deploymentdeployed ahead of the textbook

Read left-to-right as knowledge, bottom-to-top as deployment. The mass toward the upper-right is the addressing-and-protocol core — address types and subnetting, SLAAC (Stateless Address Autoconfiguration), Neighbor Discovery, the IPv6 firewall — run in production. The comb of drop-lines below it is the interoperability and transition layer: prefix delegation, IPv6-over-PPP, the legacy tunnel mechanisms — read closely, run thinly or not at all.

The topography

The full leaf-level ledger, grouped by topic — the addressing model and the protocol mechanics, the packet structure, the IPv6 security surface, the transition mechanisms and the interoperability layer. Each row carries its own two verdicts — what is known and what is deployed — and the field note that earned them, quoted verbatim from the assessment.

LeafKnowledgeDeploymentField note
IPv6 IntroductionK̄ 3.7 · Ē 3.6 · 10 leaves · 5 splits
Address Types, Notation & Subnetting5Teach5Teachprefer same scope as the destination, longest matching prefix, temporary over EUI-64, configurable policy table -- correct
Reserved Addressesstudied ahead4Fluent3ConfidentPicked 2001:db8::/32 as the documentation prefix over the ORCHID (2001:10::/28) / site-local (fec0::/10) / discard (100::/64) expert traps.
IPv4 vs IPv6studied ahead4Fluent3ConfidentKnew IPv6 drops broadcast for multicast ND/DHCPv6. BUT volunteered: 'I don't fully understand multicast vs anycast vs broadcast — can't explain to others.' The cast-taxonomy is operational-recognition, not teachable — the knowledge edge running through anycast (no-idea) + MLD (no-idea). on the v4/v6 diff itself /.
SLAAC EUI-645Teach5TeachEUI-64 = insert ff:fe + flip the U/L bit; RFC4941 privacy/temporary addresses hide the MAC + rotate, used as source for outbound; DHCPv6 DUID+IAID identity, MAC-independent
Link-Localdeployed ahead2Aware3ConfidentEDGE: knew link-local exists + EUI-64 formation, but thought it Ethernet-only; missed that it's MANDATORY on every interface type AND is the IPv6 default-route next-hop (the gateway is a link-local address). Address known, routing-plane role not
Globaldeployed ahead4Fluent5TeachGUA = 2000::/3, only those globally routable. OPERATES a real global /48 as a vISP (lived global-scope addressing).
Multicast3Confident3ConfidentIdentified ff02::1:ff3a:b1c2 as solicited-node multicast (low-24-bits target) — UP from v1's Aware/dk on solicited-node construction. BUT can't explain multicast/anycast/broadcast distinctions 'to others' (see ipv4-vs-ipv6) → operational recognition, not teachable theory.
Anycast1Learning1LearningHonest don't-know: 'no idea' on anycast (an ordinary unicast address on multiple nodes, routing delivers to the nearest). Part of the cast-taxonomy knowledge edge — never used anycast.
Unique-Local (ULA)5Teach5TeachULA fc00::/7 (fd00::/8) = private site-routable RFC1918 analogue, independent of the ISP prefix
Special Addressesstudied ahead4Fluent3ConfidentSpecial-purpose blocks solid — documentation prefix, GUA 2000::/3, solicited-node multicast format all correct. Inferred from those.
IPv6 ProtocolK̄ 4.2 · Ē 3.8 · 5 leaves · 2 splits
Stateless SLAAC5Teach5TeachM=stateful DHCPv6, O=other-info-only, both 0 = pure SLAAC -- deployment-facing
Stateful DHCPv6studied ahead4Fluent3ConfidentStateful addressing is driven by the RA M (Managed) flag. Knows the RA flag model; runs mostly SLAAC/NAT6 in practice.
Neighbor Discovery5Teach5TeachNDP/DAD concept solid
IPv6 Routing Basics3Confident3ConfidentA static route with an fe80:: next-hop MUST also pin the outgoing interface (link-local isn't globally unique) — the EXACT v1 'link-local control-plane' question, now CORRECT. Routes IPv6 in the vISP.
Prefixstudied ahead4Fluent3ConfidentOn-link /64 advertised with A+L flags → hosts SLAAC their own address. Deploys RA.
IPv6 PacketK̄ 4.0 · Ē 3.0 · 4 leaves · 3 splits
Header Fieldsstudied ahead4Fluent2AwareIPv6 base header is a fixed 40 bytes with NO checksum. Knows the facts; not a byte-level operator (home use).
Next-Header / Daisy-Chainingstudied ahead3Confident2AwareHbH-Options-must-come-first + only-header-transit-routers-examine correct (by reasoning). Self-flag: 'I use IPv6 at home mostly without being deep on packet structure' → first-principles knowledge, not packet-level operation.
Fragmentationstudied ahead4Fluent3ConfidentOnly the SOURCE fragments via a Fragment ext-header; routers send Packet-Too-Big. PMTUD/MTU he tunes via tunnels (MTCRE).
Path MTU Discovery5Teach5TeachIPv6 routers never fragment; a router sends ICMPv6 Packet-Too-Big to the source -> source PMTUD/source-fragments; differs from IPv4
IPv6 SecurityK̄ 3.1 · Ē 2.7 · 10 leaves · 2 splits
ICMPv65Teach5TeachKnew exactly why a blanket 'drop all ICMPv6' is dangerous — ND + PMTUD ride ICMPv6. Security-engineer core; writes IPv6 firewalls.
RS / RA5Teach5Teachrogue-RA defense = RA Guard at L2 on the switch/bridge, drops RAs on non-router ports; his security lens extends to IPv6
NS / NA2Aware2AwareHonest don't-know on the NS→NA resolution exchange (NS to the target's solicited-node multicast, unicast NA reply) — DESPITE recognizing the solicited-node address FORMAT in Q1. Recognition of formats, not reconstruction of the protocol flow. The NDP-mechanics knowledge edge.
NUD (Neighbor Unreachability Detection)1Learning1LearningHonest don't-know on NUD (a STALE entry probes only on USE: STALE→DELAY→PROBE, not a background timer). NDP-mechanics edge.
Managed / Other Config Flags2Aware2AwareEDGE: A=autonomous and L=on-link are independent; A=1/L=0 = SLAAC an address but route via the gateway even for same-prefix neighbors (the ISP point-to-point /64 pattern). Taught in-session. Part of the link-local-control-plane cluster
Redirect1Learning1LearningHonest don't-know: 'no idea about ICMPv6 Redirect'. (A hardened edge should NOT accept Redirects — a forged one hijacks a host's next-hop.) NDP-adjacent control-message edge.
MLD (Multicast Listener Discovery)1Learning1LearningHonest don't-know: 'no idea about MLD' (IPv6's IGMP; snooping prunes multicast on switches). Matches the MTCSWE 'don't know much about IGMP/multicast' — the multicast soft spot is CROSS-CERT.
Temporary Addresses (RFC4941)studied ahead4Fluent2AwareRFC4941 privacy addresses = randomized interface-ID so SLAAC can't be tracked by the MAC-derived EUI-64. Host-side feature mostly.
IPv6 Firewall5Teach5TeachICMPv6 essential (NDP/PMTUD); permit specific types
IPsec AH / ESP / AH+ESP (IPv6)studied ahead5Teach3ConfidentESP encrypts (+ can authenticate), AH authenticates ONLY → ESP for confidentiality. Security-engineer Teach on IPsec design; WireGuard is his deployed transport so IPsec.
Transition MechanismsK̄ 2.8 · Ē 1.6 · 5 leaves · 4 splits
Dual Stack4Fluent4FluentHappy Eyeballs (RFC8305) — race A/AAAA, prefer IPv6, fast fallback to v4. Runs native dual-stack.
6to4studied ahead2Aware1LearningMISS. Owner: 'never deployed/used/practiced any of 6to4 or 6rd — always native IPv6 from ISP, or IPv6+NAT over WireGuard.' Legacy-retired-by-choice (cf. Nstreme/web-proxy informed-obsolescence).
6RDstudied ahead2Aware1Learning6rd = the ISP-run 6to4 variant using the ISP's own prefix (not 2002::/16); legacy. Never deployed (native IPv6 makes it moot).
Teredostudied ahead3Confident1LearningTeredo = IPv6 over UDP through IPv4 NAT (2001::/32), last-resort, high-latency/often-firewalled. 'Aware, never practiced.'
DS-Litestudied ahead3Confident1LearningDS-Lite = IPv4-over-IPv6 to a carrier AFTR/CGN for IPv4 service on an IPv6-only access net. 'Aware of concept, never implemented.'
InteroperabilityK̄ 3.8 · Ē 2.5 · 12 leaves · 10 splits
IPv6 Poolstudied ahead4Fluent2AwarePool = holds the delegated prefix, hands out smaller sub-prefixes. Owns + operates a real global /48 (vISP) but PD sub-delegation via /ipv6 pool not yet deployed.
DHCPv6-PD Server/Clientstudied ahead4Fluent2AwareDesign known cold — nailed the IA_PD dhcp-client config (request=prefix + pool-name), pool sub-delegation, and the IPV6CP-brings-link-local / PD-delivers-the-prefix split all. But NOT deployed: customer delivery is NAT6 today, PD/PPP-IPv6 still in build-out. CORRECTION of v1's inferred + 'BNG-PD his strongest IPv6 surface' framing — that delivery model was never realized (genchi-genbutsu, owner-reported 2026-06-27).
DHCPv6 Clientstudied ahead4Fluent2AwareRead dhcp-client request=prefix + pool-name + pool-prefix-length exactly as IA_PD→pool→LAN sub-assignment. Experience thin — customer IPv6 via NAT6 today, PD client not in production (see dhcpv6-pd correction).
IPIPv6studied ahead4Fluent3ConfidentIPIPv6 = L3 point-to-point tunnel over IPv6.
EoIPv6studied ahead4Fluent3ConfidentEoIPv6 bridges L2 (Ethernet) vs GRE6/IPIPv6 which carry L3; all add header overhead lowering payload MTU. Uses EoIP (MTCRE).
GRE6studied ahead4Fluent3ConfidentGRE6 = L3 tunnel over IPv6, distinguished from EoIP's L2.
DNS & Reverse DNSdeployed ahead2Aware3ConfidentMISS — picked byte-reversed in-addr.arpa6 (real = nibble-reversed ip6.arpa, one hex digit per label). Owner: 'I don't fully understand reverse DNS (v4 or v6).' Forward/AAAA he runs fine (MTCNA DNS Teach); the gap is the REVERSE concept, cross-protocol not IPv6-specific.
NTP3Confident3ConfidentNTP just works over IPv6 transport — point the client at an IPv6 server.
PPP IPv6studied ahead4Fluent1LearningIPV6CP brings up link-local only; the routed /56 is delegated SEPARATELY via DHCPv6-PD. Owner: 'still struggling to deploy IPv6 via PPP for customers… for now deploying via NAT6, no DHCPv6-PD experience yet' — the live build-out edge.
Routing Global & Link-Local2Aware2AwareEDGE: thought OSPFv3 uses global adjacencies + drops DR/BDR; actually adjacencies/next-hops over LINK-LOCAL, keeps DR/BDR + areas, and has NO built-in auth (relies on IPsec). Likely runs no IPv6 IGP in production. Link-local-control-plane cluster
Feature Gaps (NAT / HotSpot / RADIUS / Policy-Routing / DHCPv6-server)studied ahead5Teach3ConfidentKnew HotSpot is IPv4-only AND volunteered the security consequence UNPROMPTED: a dual-stack HotSpot is a 'massive auth-bypass vector out of the box' — the captive portal intercepts only v4, so IPv6 walks around it. Insight EXCEEDS the question. ('never deployed HotSpot on dual-stack').
IPv6 Toolsstudied ahead5Teach3ConfidentIPv6 neighbor cache = /ipv6 neighbor (the NDP table, ARP analog). Daily diagnostic.

The edges

The lead edge is the one a customer would feel: DHCPv6 Prefix Delegation over PPP. The design is known cold — the prefix-delegation client, the pool that sub-delegates, the way IPv6-over-PPP brings up only the link-local address while the routed prefix is delegated separately — yet it is not the delivery model in production, where customer IPv6 currently rides NAT6 and a WireGuard peer-to-peer path. Around it sit the rest of the studied-ahead leaves: packet internals read from first principles rather than operated, the transition mechanisms understood and retired by choice, and the Neighbor-Discovery control messages where the recorded verdict is the owner's own “no idea.” Each gap is quoted below exactly as the assessment recorded it.

Knowledge ahead of deployment

23

Known deeper than it currently runs — named, not rounded over.

  • PPP IPv6know 4 Fluent→run 1 Learning

    IPV6CP brings up link-local only; the routed /56 is delegated SEPARATELY via DHCPv6-PD. Owner: 'still struggling to deploy IPv6 via PPP for customers… for now deploying via NAT6, no DHCPv6-PD experience yet' — the live build-out edge.

  • Header Fieldsknow 4 Fluent→run 2 Aware

    IPv6 base header is a fixed 40 bytes with NO checksum. Knows the facts; not a byte-level operator (home use).

  • Temporary Addresses (RFC4941)know 4 Fluent→run 2 Aware

    RFC4941 privacy addresses = randomized interface-ID so SLAAC can't be tracked by the MAC-derived EUI-64. Host-side feature mostly.

  • IPsec AH / ESP / AH+ESP (IPv6)know 5 Teach→run 3 Confident

    ESP encrypts (+ can authenticate), AH authenticates ONLY → ESP for confidentiality. Security-engineer Teach on IPsec design; WireGuard is his deployed transport so IPsec.

  • Teredoknow 3 Confident→run 1 Learning

    Teredo = IPv6 over UDP through IPv4 NAT (2001::/32), last-resort, high-latency/often-firewalled. 'Aware, never practiced.'

  • DS-Liteknow 3 Confident→run 1 Learning

    DS-Lite = IPv4-over-IPv6 to a carrier AFTR/CGN for IPv4 service on an IPv6-only access net. 'Aware of concept, never implemented.'

  • IPv6 Poolknow 4 Fluent→run 2 Aware

    Pool = holds the delegated prefix, hands out smaller sub-prefixes. Owns + operates a real global /48 (vISP) but PD sub-delegation via /ipv6 pool not yet deployed.

  • DHCPv6-PD Server/Clientknow 4 Fluent→run 2 Aware

    Design known cold — nailed the IA_PD dhcp-client config (request=prefix + pool-name), pool sub-delegation, and the IPV6CP-brings-link-local / PD-delivers-the-prefix split all. But NOT deployed: customer delivery is NAT6 today, PD/PPP-IPv6 still in build-out. CORRECTION of v1's inferred + 'BNG-PD his strongest IPv6 surface' framing — that delivery model was never realized (genchi-genbutsu, owner-reported 2026-06-27).

    Run
    No production DHCPv6-PD deployment yet — operates a real global /48 (vISP) but delivers customer IPv6 via NAT6 + WireGuard-p2p; IPv6-over-PPP still being brought up. 'No experience configuring DHCPv6-PD yet' (owner, 2026-06-27).
  • DHCPv6 Clientknow 4 Fluent→run 2 Aware

    Read dhcp-client request=prefix + pool-name + pool-prefix-length exactly as IA_PD→pool→LAN sub-assignment. Experience thin — customer IPv6 via NAT6 today, PD client not in production (see dhcpv6-pd correction).

  • Feature Gaps (NAT / HotSpot / RADIUS / Policy-Routing / DHCPv6-server)know 5 Teach→run 3 Confident

    Knew HotSpot is IPv4-only AND volunteered the security consequence UNPROMPTED: a dual-stack HotSpot is a 'massive auth-bypass vector out of the box' — the captive portal intercepts only v4, so IPv6 walks around it. Insight EXCEEDS the question. ('never deployed HotSpot on dual-stack').

  • IPv6 Toolsknow 5 Teach→run 3 Confident

    IPv6 neighbor cache = /ipv6 neighbor (the NDP table, ARP analog). Daily diagnostic.

  • Reserved Addressesknow 4 Fluent→run 3 Confident

    Picked 2001:db8::/32 as the documentation prefix over the ORCHID (2001:10::/28) / site-local (fec0::/10) / discard (100::/64) expert traps.

  • IPv4 vs IPv6know 4 Fluent→run 3 Confident

    Knew IPv6 drops broadcast for multicast ND/DHCPv6. BUT volunteered: 'I don't fully understand multicast vs anycast vs broadcast — can't explain to others.' The cast-taxonomy is operational-recognition, not teachable — the knowledge edge running through anycast (no-idea) + MLD (no-idea). on the v4/v6 diff itself /.

  • Special Addressesknow 4 Fluent→run 3 Confident

    Special-purpose blocks solid — documentation prefix, GUA 2000::/3, solicited-node multicast format all correct. Inferred from those.

  • Stateful DHCPv6know 4 Fluent→run 3 Confident

    Stateful addressing is driven by the RA M (Managed) flag. Knows the RA flag model; runs mostly SLAAC/NAT6 in practice.

  • Prefixknow 4 Fluent→run 3 Confident

    On-link /64 advertised with A+L flags → hosts SLAAC their own address. Deploys RA.

  • Next-Header / Daisy-Chainingknow 3 Confident→run 2 Aware

    HbH-Options-must-come-first + only-header-transit-routers-examine correct (by reasoning). Self-flag: 'I use IPv6 at home mostly without being deep on packet structure' → first-principles knowledge, not packet-level operation.

  • Fragmentationknow 4 Fluent→run 3 Confident

    Only the SOURCE fragments via a Fragment ext-header; routers send Packet-Too-Big. PMTUD/MTU he tunes via tunnels (MTCRE).

  • 6to4know 2 Aware→run 1 Learning

    MISS. Owner: 'never deployed/used/practiced any of 6to4 or 6rd — always native IPv6 from ISP, or IPv6+NAT over WireGuard.' Legacy-retired-by-choice (cf. Nstreme/web-proxy informed-obsolescence).

  • 6RDknow 2 Aware→run 1 Learning

    6rd = the ISP-run 6to4 variant using the ISP's own prefix (not 2002::/16); legacy. Never deployed (native IPv6 makes it moot).

  • IPIPv6know 4 Fluent→run 3 Confident

    IPIPv6 = L3 point-to-point tunnel over IPv6.

  • EoIPv6know 4 Fluent→run 3 Confident

    EoIPv6 bridges L2 (Ethernet) vs GRE6/IPIPv6 which carry L3; all add header overhead lowering payload MTU. Uses EoIP (MTCRE).

  • GRE6know 4 Fluent→run 3 Confident

    GRE6 = L3 tunnel over IPv6, distinguished from EoIP's L2.

Deployed ahead of the textbook

3

Run in production a notch beyond the studied internals — the rarer direction.

  • Link-Localknow 2 Aware→run 3 Confident

    EDGE: knew link-local exists + EUI-64 formation, but thought it Ethernet-only; missed that it's MANDATORY on every interface type AND is the IPv6 default-route next-hop (the gateway is a link-local address). Address known, routing-plane role not

    Known
    knew formation/EUI-64, not the routing-plane role
    Run
    runs IPv6 edge but no IPv6 IGP
  • Globalknow 4 Fluent→run 5 Teach

    GUA = 2000::/3, only those globally routable. OPERATES a real global /48 as a vISP (lived global-scope addressing).

  • DNS & Reverse DNSknow 2 Aware→run 3 Confident

    MISS — picked byte-reversed in-addr.arpa6 (real = nibble-reversed ip6.arpa, one hex digit per label). Owner: 'I don't fully understand reverse DNS (v4 or v6).' Forward/AAAA he runs fine (MTCNA DNS Teach); the gap is the REVERSE concept, cross-protocol not IPv6-specific.

The warrant

Third-party confirmation of the IPv6 depth shown above.

IPv6 sits on the addressing and routing planes it shares with the rest of the stack. Where it connects:

The questions

Can you deliver customer IPv6 by DHCPv6-PD prefix delegation, or only via NAT6?
The honest verdict: today I deliver customer IPv6 through NAT6 and a WireGuard peer-to-peer path; DHCPv6-PD over PPP is my build-out edge — the design I have studied and exam-passed (MTCIPv6E 92%), not yet the production delivery model. The mechanics are not a mystery. In RouterOS 7 the prefix-delegation client is /ipv6 dhcp-client add request=prefix pool-name=… pool-prefix-length=64 interface=…; the delegated prefix lands in a named /ipv6 pool, and each LAN /64 is then assigned from-pool=… advertise=yes so hosts SLAAC their own addresses. Over PPP the client attaches to the pppoe-out interface: IPV6CP brings up only the link-local address, and the routed prefix arrives separately through DHCPv6-PD. RouterOS’s own DHCPv6 server can delegate prefixes, not addresses. I lab that path before I bill it — that ordering is the point of this page.
Is delivering IPv6 over NAT6 a real deployment, or a workaround?
It is a real, running deployment — I operate a global /48 as a virtual ISP and hand customers working IPv6 through it — but NAT6 is a deliberate interim, not the destination; native prefix delegation is. The mechanism, publicly: RouterOS supports IPv6-to-IPv6 NAT (NAT66) from version 7.1 onward, configured under /ipv6 firewall nat — action=masquerade chain=srcnat out-interface=… for a dynamic upstream address, or action=src-nat … to-address=… for a static one — typically with a ULA prefix (fd00::/8) advertised on the LAN. NAT was the IPv4 crutch IPv6 was designed to remove, which is exactly why prefix delegation, not NAT6, is the path I am building toward.
What IPv6 work is genuinely production-proven?
The addressing model and the security surface. I write IPv6 firewalls in production, operate a global /48, and run native dual-stack; the IPv6 firewall, ICMPv6 handling, and rogue-RA defence (RA Guard at the switch) are security-engineer core here — graded at teaching depth and deployed. One field-tested example: a common IPv6 mistake is to “drop all ICMPv6” the way one filters noise on IPv4 — but Neighbor Discovery and Path MTU Discovery both ride ICMPv6, so a blanket drop breaks address resolution and silently black-holes large packets. RouterOS’s own default IPv6 firewall reflects this: it explicitly accepts protocol=icmpv6 before the final drop, and permits UDP/546 from fe80::/10 so the DHCPv6-PD client still works. Permit the ICMPv6 types you need; drop the rest.

Taking IPv6 into production?

If it is IPv6 addressing, a dual-stack firewall, or NAT6 delivery on RouterOS, that is ground I run today. If it is customer prefix delegation over PPP, I will tell you it is my build-out edge — and lab it before I bill it — before the work starts, not after.

Start the conversation