IPFW IPFW + IPv6 + NPTv6: Faulty prefix translation?

[BSDlarry]

Hi,

I've played around with IPv6-to-IPv6 network prefix translation for several days now but unfortunately I couldn't get NPTv6 up and running so far.
By using tcpdump on ipfw0 I've noticed that IPFW seems to always add an additional group with hexadecimal digits to my predefined int_prefix argument.
I don't want to rule out that I misunderstand something. Can anybody help?

With the command ...

ipfw nptv6 NPT create int_prefix fd24:ca16:8eb0:5ab6:: ext_prefix 2xxx:1111:2222:3333:: prefixlen 64

... I created the NPTv6 instance "NPT". If I understand ipfw(8) correctly, all incoming packets with prefix 2xxx:1111:2222:3333: should be translated to fd24:ca16:8eb0:5ab6:
Am I on the right track so far?


This is what tcpdump shows. Unfortunately I don't have an explanation why the internal address gets additional digits:

IP6 2604:6600:2005:3:fc2f:e93a:9b6:f469.9466 > 2xxx:1111:2222:3333::e.80: Flags , seq 1076004423, win 28800, options [mss 1440,nop,wscale 7], length 0
IP6 2604:6600:2005:3:fc2f:e93a:9b6:f469.9466 > fd24:ca16:8eb0:5ab6:bc5d::e.80: Flags , seq 1076004423, win 28800, options [mss 1440,nop,wscale 7], length 0
IP6 2604:6600:2005:3:fc2f:e93a:9b6:f469.9466 > fd24:ca16:8eb0:5ab6:bc5d::e.80: Flags , seq 1076004423, win 28800, options [mss 1440,nop,wscale 7], length 0
IP6 2604:6600:2005:3:fc2f:e93a:9b6:f469.9466 > fd24:ca16:8eb0:5ab6:bc5d::e.80: Flags , seq 1076004423, win 28800, options [mss 1440,nop,wscale 7], length 0

I would expect that 2xxx:1111:2222:3333::e is translated to fd24:ca16:8eb0:5ab6::e, not to fd24:ca16:8eb0:5ab6:bc5d::e

It would be great if someone could explain why "bc5d" is added after fd24:ca16:8eb0:5ab6:


Thanks in advance!

 

[covacat]

RFC 6296: IPv6-to-IPv6 Network Prefix Translation

This document describes a stateless, transport-agnostic IPv6-to-IPv6 Network Prefix Translation (NPTv6) function that provides the address-independence benefit associated with IPv4-to-IPv4 NAT (NAPT44) and provides a 1:1 relationship between addresses in the "inside" and "outside" prefixes...

datatracker.ietf.org

2.6.  Checksum-Neutral Mapping

   When a change is made to one of the IP header fields in the IPv6
   pseudo-header checksum (such as one of the IP addresses), the
   checksum field in the transport layer header may become invalid.
   Fortunately, an incremental change in the area covered by the
   Internet standard checksum [RFC1071] will result in a well-defined
   change to the checksum value [RFC1624].  So, a checksum change caused
   by modifying part of the area covered by the checksum can be
   corrected by making a complementary change to a different 16-bit
   field covered by the same checksum.

   The NPTv6 mapping mechanisms described in this document are checksum-
   neutral, which means that they result in IP headers that will
   generate the same IPv6 pseudo-header checksum when the checksum is
   calculated using the standard Internet checksum algorithm [RFC1071].
   Any changes that are made during translation of the IPv6 prefix are
   offset by changes to other parts of the IPv6 address.  This results
   in transport layers that use the Internet checksum (such as TCP and
   UDP) calculating the same IPv6 pseudo-header checksum for both the
   internal and external forms of the same datagram, which avoids the
   need for the NPTv6 Translator to modify those transport layer headers
   to correct the checksum value.

   The outgoing checksum correction is achieved by making a change to a
   16-bit section of the source address that is not used for routing in
   the external network.  Due to the nature of checksum arithmetic, when
   the corresponding correction is applied to the same bits of
   destination address of the inbound packet, the Destination Address
   (DA) is returned to the correct internal value.