<html>
    <head>
      <base href="https://bugzilla.netfilter.org/" />
    </head>
    <body><table border="1" cellspacing="0" cellpadding="8">
        <tr>
          <th>Bug ID</th>
          <td><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - IPv6 NAT translates to addresses outside of specified range"
   href="https://bugzilla.netfilter.org/show_bug.cgi?id=1342">1342</a>
          </td>
        </tr>

        <tr>
          <th>Summary</th>
          <td>IPv6 NAT translates to addresses outside of specified range
          </td>
        </tr>

        <tr>
          <th>Product</th>
          <td>netfilter/iptables
          </td>
        </tr>

        <tr>
          <th>Version</th>
          <td>unspecified
          </td>
        </tr>

        <tr>
          <th>Hardware</th>
          <td>x86_64
          </td>
        </tr>

        <tr>
          <th>OS</th>
          <td>Debian GNU/Linux
          </td>
        </tr>

        <tr>
          <th>Status</th>
          <td>NEW
          </td>
        </tr>

        <tr>
          <th>Severity</th>
          <td>normal
          </td>
        </tr>

        <tr>
          <th>Priority</th>
          <td>P5
          </td>
        </tr>

        <tr>
          <th>Component</th>
          <td>NAT
          </td>
        </tr>

        <tr>
          <th>Assignee</th>
          <td>netfilter-buglog@lists.netfilter.org
          </td>
        </tr>

        <tr>
          <th>Reporter</th>
          <td>zrm@trustiosity.com
          </td>
        </tr></table>
      <p>
        <div>
        <pre>Take a rule like this:

ip6tables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source
1000::1:ffff:ffff-1000::2:0:0

The kernel was then observed choosing the address 1000::2:ffff:ffff as the
translation, which is outside the specified range.

This is the code in find_best_ips_proto() in nf_nat_core.c. It assumes that in
each u32 of the IPv6 address, the minimum value is not larger than the maximum,
even though that is only required for the most significant u32 of the address.
It also assumes the minimum will be zero (full_range) whenever the previously
chosen u32 was not the maximum, which may not be true when the previous chosen
u32 was the minimum.

It might not be that unreasonable to just refuse IPV6 NAT ranges that split
like this, but in that case it should be documented and there should be an
error when you try to insert the rule.</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are watching all bug changes.</li>
      </ul>
    </body>
</html>