[RFC/RFT] NPTv6 (network prefix translation for IPv6) module for ipfw

[ae]

Summary

This patch adds ipfw_nptv6(4) module with NPTv6 implementation (RFC 6296) that works together with ipfw.
The module implemented as ipfw's external action module. When it is loaded, it registers as eaction and can be used in rules.
The usage pattern is similar to ipfw_nat(4). All matched by rule traffic goes to the NPT module.
User can create NPT instance with ipfw nptv6 NAME create opts command. Then this instance can be used in ipfw's rules.

# ipfw nptv6 NPT create int_prefix FD01:0203:0405:: ext_prefix 2001:0DB8:0001:: prefixlen 48
# ipfw add allow icmp6 from any to any icmp6types 135,136
# ipfw add nptv6 NPT ip6 from any to any

Test Plan

We will use and test it in near future, but currently I did only basic tests.
I configured IPv6 via tunnelbroker.net:

     [ Internet ]
          ^
          |
   [ tunnelbroker ]
  2001:470:7ad7::/48
2001:470:1f14:7bf::1/64
          ^
          |
2001:470:1f14:7bf::2/64 gif0
     [ NPT Host ]
  fd00:dead:c0de::1/48  em0
          ^
          |
  fd00:dead:c0de::2/48  em0
    [ Client Host ]

NPT configs:

route add -6 default 2001:470:1f15:7bf::1

# ipfw nptv6 all list
nptv6 NPT int_prefix fd00:dead:c0de:: ext_prefix 2001:470:7ad7:: prefixlen 48
# ipfw show
00100     0       0 allow ipv6-icmp from any to any icmp6types 135,136
00200  7097 2965601 nptv6 NPT ip6 from any to any 
65535 29757 7630936 allow ip from any to any

Client configs:

# route add -6 default fd00:dead:c0de::1
# ping6 www.freebsd.org

On the NTP Host:

# tcpdump -ni em0 ip6
15:47:56.904218 IP6 fd00:dead:c0de::2 > 2001:1900:2254:206a::50:0: ICMP6, echo request, seq 0, length 16
15:47:57.117328 IP6 2001:1900:2254:206a::50:0 > fd00:dead:c0de::2: ICMP6, echo reply, seq 0, length 16
15:50:07.032047 IP6 2a02:6b8:0:204::1 > fd00:dead:c0de::2: ICMP6, echo request, seq 0, length 16
15:50:07.032414 IP6 fd00:dead:c0de::2 > 2a02:6b8:0:204::1: ICMP6, echo reply, seq 0, length 16

# tcpdump -ni gif0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on gif0, link-type NULL (BSD loopback), capture size 262144 bytes
15:47:56.904259 IP6 2001:470:7ad7:fd44::2 > 2001:1900:2254:206a::50:0: ICMP6, echo request, seq 0, length 16
15:47:57.117312 IP6 2001:1900:2254:206a::50:0 > 2001:470:7ad7:fd44::2: ICMP6, echo reply, seq 0, length 16
15:50:07.032022 IP6 2a02:6b8:0:204::1 > 2001:470:7ad7:fd44::2: ICMP6, echo request, seq 0, length 16
15:50:07.032428 IP6 2001:470:7ad7:fd44::2 > 2a02:6b8:0:204::1: ICMP6, echo reply, seq 0, length 16

From Internet:

# ping6 2001:470:7ad7:fd44::2

Also I tried to open www.freebsd.org, www.google.com, ipv6-test.com from Client. All worked.

[ae]

Use ipfw_check_object_name() and add patch to man page.

[ae]

Restore sys/modules that was lost in the last update.

[hrs]

Excellent! Thank you for your work. I will review and test it.

[hrs]

I am still reviewing this and your NAT64 patch and probably I will be able to get back on Monday.

[hrs]

sbin/ipfw/ipfw.8

2937 ↗

(On Diff #16472)

I like to add the following:

"Note that the prefix translation rules are silently ignored when IPv6 packet forwarding is disabled. To enable the packet forwarding, set the sysctl variable net.inet6.ip6.forwarding to 1."

sbin/ipfw/nptv6.c

214 ↗

(On Diff #16472)

prefixlen handling looks a bit confusing for me, and it seems that p is not initialized. Does a prefixlen modifier with no /nn specification really work?

I tried to fix it by using this patch: https://people.allbsd.org/~hrs/FreeBSD/nptv6.c.20160610-1.diff I think using the longest prefix in the three possible ways to configure is most consistent.

sys/netpfil/ipfw/nptv6/nptv6.c

811 ↗

(On Diff #16472)

This assert may cause a panic upon kldunload because the callback function comes after ipfw_del_eaction(). Although generally speaking it is not safe to destroy a named object without a write-lock, I think we can drop this here if this is called only after ipfw_del_eaction().

[hrs]

sbin/ipfw/ipfw.8

116 ↗

(On Diff #16472)

A trailing whitespace :)

[ae]

sys/netpfil/ipfw/nptv6/nptv6.c

811 ↗

(On Diff #16472)

I think this can be fixed if we just take IPFW_UH_WLOCK() in nptv6_uninit() while calling callback to protect from configuration change.

[ae]

Update NPTv6 implementation to resolve found issues

o Add a note about net.inet6.ip6.forwarding
o Fix locking issue in nptv6_uninit().
o Fix prefixes handling in ipfw(8).
o Move macro definitions to the top of file.
o Make V_nptv6_eid static and move it into nptv6.c.

[bz]

I haven;t looked at the code; my only comment currently is: why does it have to be ipfw specific; could this be "library code" that could be an independent pfil module, be used from pf as well?

[ae]

In D6420#143812, @bz wrote:

I haven;t looked at the code; my only comment currently is: why does it have to be ipfw specific; could this be "library code" that could be an independent pfil module, be used from pf as well?

It is because we use ipfw(4) :)
The code that does translation is small - just several small functions. So it can be moved to some library. Probably we will adopt it to use with netmap/DPDK in some near future.

[ae]

So, are there any objections on this?

[hrs]

No objection from me. Thank you for your good work!