Bringing MAP‑E CE to OpenBSD 7.8: An Experimental Implementation

Thesis

The openbsd‑mape‑ce repository represents a rare convergence of community‑driven networking research and the OpenBSD operating system’s emphasis on clean, auditable code. By delivering a complete, though experimental, implementation of MAP‑E Customer Edge (CE) as defined in RFC 7597, the project equips OpenBSD 7.8 routers with the ability to translate IPv4 traffic into IPv6‑encapsulated packets, a capability that many commercial ISP gear provides but that has long been absent from the OpenBSD code base.

---

Core Arguments and Evidence

1. A Minimal yet Complete Patch Set

• pf(4) extension – The pf-map-e-ce patch, publicly available since 2021, adds a new NAT rule type (map‑e‑portset) that permits the port‑preserving translation required by MAP‑E. The patch integrates cleanly with the existing PF rule syntax, allowing administrators to express MAP‑E mappings directly in /etc/pf.conf.
• dhcp6leased augmentation – By patching dhcp6leased(8), the project injects MAP‑E specific DHCPv6 options (the MAP‑E BR and MAP‑E rule attributes). This enables the router to obtain the necessary prefix delegation and port‑allocation parameters from the ISP without external scripts.
• User‑space helper suite (maped) – The Perl daemon maped orchestrates the creation of a GIF tunnel, populates PF anchors, and watches the DHCP lease file for changes. Its helpers live under /usr/local/libexec/maped, keeping the core system untouched.

The repository supplies a single, reproducible workflow: clone, apply two patches, rebuild the kernel and userland tools, and enable the maped service. The detailed README walks a sysadmin through each command, from downloading the OpenBSD source tarballs to verifying the resulting gif0 interface and PF rules.

2. Practical Automation for a Complex Feature

MAP‑E CE is conceptually simple—map an IPv4 address and port range onto an IPv6 prefix—but operationally it requires tight coordination between DHCPv6, the packet filter, and the tunnel interface. The maped daemon abstracts this coordination:

• It parses /etc/dhcp6leased.conf for the request mape directive.
• Upon lease acquisition, it extracts the BR (BR‑IPv6) and rule parameters (offset, PSID length, etc.).
• It writes a PF anchor (mape) containing the appropriate map‑e‑portset rules, then reloads PF.
• It configures the GIF tunnel with the encapsulated IPv6 endpoints.

By automating these steps, the project lowers the barrier for OpenBSD operators to experiment with MAP‑E, a feature traditionally reserved for vendor‑specific firmware.

3. Transparency and Reproducibility

All patches, scripts, and configuration examples are hosted on a public sourcehut repository (https://git.sr.ht/~atmosx/openbsd-mape-ce). The commit history shows incremental improvements—renaming the helper suite to maped, adding a pf.conf example, and cleaning up the sample maped.conf. The build instructions rely exclusively on the official OpenBSD source tarballs, ensuring that the resulting binaries can be reproduced on any 7.8 installation.

---

Implications for the OpenBSD Community

1. Expanding OpenBSD’s ISP‑grade feature set – While OpenBSD has long excelled at security and correctness, its networking stack has occasionally lagged behind commercial routers in terms of carrier‑grade services. MAP‑E CE fills a notable gap, allowing OpenBSD to act as a customer‑edge device in IPv6‑only ISP deployments that still need to serve IPv4 clients.
2. Encouraging community‑driven kernel extensions – The project demonstrates a viable workflow for contributing substantial kernel patches without upstream acceptance. Other developers may follow suit for features such as LISP, SR‑v6, or advanced traffic‑engineering extensions.
3. Risk considerations – The author explicitly labels the implementation experimental and advises against production use. Since the patches modify PF’s NAT core and the DHCP daemon, any bugs could affect firewall correctness or lease handling. Operators must test in isolated environments before considering deployment.

---

Counter‑Perspectives and Limitations

• Maintenance burden – The patches target OpenBSD 7.8. Future releases will require re‑patching, and the lack of upstream integration means the OpenBSD maintainers will not provide security updates for the modified code. This could deter long‑term adopters.
• Performance trade‑offs – MAP‑E relies on encapsulation (IPv4‑in‑IPv6) and PF’s NAT processing. While PF is efficient, the additional per‑packet encapsulation overhead may become noticeable on high‑throughput links, especially on hardware without offload support for IPv6‑in‑IPv4.
• Alternative approaches – Some operators might prefer using a dedicated MAP‑E appliance or a Linux‑based router with mature implementations (e.g., softwire4 in the Linux kernel). The OpenBSD solution, while elegant, may not yet match the feature completeness or tooling ecosystem of those alternatives.

---

Conclusion

The openbsd‑mape‑ce project offers a thoughtfully assembled set of patches and automation tools that bring MAP‑E CE to OpenBSD 7.8, opening the door for experimental deployments in IPv6‑only ISP environments. Its transparent development process, clear documentation, and reliance on standard OpenBSD build practices make it a valuable reference for anyone interested in extending the operating system’s networking capabilities. However, the experimental nature of the code, the need for ongoing maintenance, and potential performance considerations mean that it remains a niche solution suited for testing and research rather than immediate production use.

---

Further Reading

• RFC 7597 – Mapping of Address and Port using Encapsulation (MAP‑E)
• OpenBSD PF manual: https://man.openbsd.org/pf.conf
• dhcp6leased(8) documentation: https://man.openbsd.org/dhcp6leased
• Project repository: https://git.sr.ht/~atmosx/openbsd-mape-ce