<div dir="ltr">> I understand the mapping concept, and this question was for when<br>> G64 already created the mapping for UDP between the IPv6 address<br>> and the IPv4 one (when using a pool4).<br><br>Are you sure you are not mistaking BIB and pool4?<br><br>pool4 is just the transport addresses the NAT64 can use to mask<br>IPv6 nodes. What's important is that it doesn't define *which* IPv6<br>nodes are masked. That is BIB's responsibility.<br><br>pool4 is just the pool of available v4 masks. The masks themselves<br>are BIB entries.<br><br>To create a UDP mapping/mask/BIB entry you have to do something<br>like<br><br> jool --bib --add --udp fg01::3e52:10b1:6fc8:f0f1:94f8#80 192.168.0.100#80<br><br>> when Jool creates a mapping between one IPv6 and an IPv4 (this<br>> would only happen on A6-initiated traffic), I would like for it<br>> to ask to the DHCP for an address instead of randomly grabbing<br>> one from the pool4.<br><br>By core nature, NAT64 does not reserve addresses; it reserves<br>*transport* addresses. In the command I wrote above, only port 80<br>of address 192.168.0.100 is reserved. Other ports of 192.168.0.100<br>can potentially belong to other IPv6 nodes.<br><br>If you need to reserve addresses, you definitely need SIIT.<br><br>> Yes, I got that. But then, when we define a pool4, it stops doing<br>> this when it maps an IPv6 traffic to an IPv4. Or maybe I don't<br>> understand the use of pool4?<br><br>pool4 does not map any v6 traffic to v4; see above.<br><br>> Agreed, but I think the problem comes from G64 that does not know<br>> that indeed .54 traffic is expected to be for it (more<br>> specifically for one of its services).<br><br>I don't think so; from the way I see it, it's a layer 2 thing.<br><br>If this is C4's routing table:<br><br> $ ip route<br> default via 192.168.0.100 dev eth0 proto static <br> <a href="http://192.168.0.0/24">192.168.0.0/24</a> dev eth0 (...) src 192.168.0.104 (...)<br><br>Then it doesn't have any way to know that it's supposed to send .54<br>packets via 192.168.0.100. The link scoped route (<a href="http://192.168.0.0/24">192.168.0.0/24</a>)<br>is more a more specific match to 192.168.0.54 than the global one<br>(<a href="http://0.0.0.0/0">0.0.0.0/0</a>) so it attempts to find .54 as a neighbor (because the<br>192.168.0 route is link-scoped).<br><br>Assuming that .54 is not in its neighbor table ($ ip neigh), it<br>sends an ARP request: "Who is 192.168.0.54?," and since G64 does<br>not have the address in its interface, nobody answers. Therefore,<br>C4 thinks .54 does not exist. Therefore, it never puts the packet<br>on the network. G64 cannot receive it in the first place.<br><br>If you are seeing the packet in G64 despite the above problem is<br>because the earlier ping managed to hack a bogus neighbor table<br>entry intr C4, mapping G64's MAC address (sort of incorrectly) to<br>.54. Assuming you can live with this, G64 will receive the packet<br>and Jool will have no problem snatching and translating it. That's<br>the reason why adding the <a href="http://192.168.0.54/32">192.168.0.54/32</a> route to C4 works; it<br>forces C4 to skip the neighbor discovery step. Because it's not<br>link scoped and is more specific than <a href="http://192.168.0.0/24">192.168.0.0/24</a>.<br><br>But this is all assuming you already added a BIB entry for whatever<br>port C4 wants to talk to! If that mapping does not exist, even if<br>Jool catches the packet, it will be unable to tell where it is<br>headed to.<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 29, 2016 at 9:10 AM, Romain Bazile <span dir="ltr"><<a href="mailto:romain.bazile@ubiant.com" target="_blank">romain.bazile@ubiant.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<p>Hi,</p>
<p><br>
</p>
<p>First of all, thanks for the answers! <br>
</p>
<p>Regarding your comments, it looks I did not made myself very
clear! I answered below.<br>
</p><span class="">
<br>
<blockquote type="cite">
<div dir="ltr">
<div>This property of remembering mappings is what makes NAT64<br>
"stateful". Its advantage is that you're using a few G64
addresses<br>
to grant a potentially large and dynamic number of IPv6 nodes<br>
access to IPv4 ones. The drawback is that IPv4 nodes cannot
start<br>
communication with v6 ones because G64 doesn't initially know
who<br>
they are talking to.<br>
<br>
(Unless you predefine mappings yourself. You can find more<br>
information at <a href="https://jool.mx/en/bib.html" target="_blank">https://jool.mx/en/bib.html</a>
and<br>
<a href="https://jool.mx/en/usr-flags-bib.html" target="_blank">https://jool.mx/en/usr-flags-bib.html</a>)<br>
</div>
</div>
</blockquote></span>
I understand the mapping concept, and this question was for when G64
already created the mapping for UDP between the IPv6 address and the
IPv4 one (when using a pool4).<br>
This drawback is exactly why I would want some kind DHCPing to
happen: I.E. when Jool creates a mapping between one IPv6 and an
IPv4 (this would only happen on A6-initiated traffic), I would like
for it to ask to the DHCP for an address instead of randomly
grabbing one from the pool4. And this mapping would have the same
TTL as the allocation from the DHCP server.<br>
<br>
I read the doc for the bib entries, it would be perfect, except my
only problem with those is that I would have to manually add every
device as soon as it appears on the network. And I'm not sure how to
do that (yet! Maybe I could broadcast a ping or use neighbour
discovery to find IPv6 devices and attribute them a fixed entry, all
from within a script that would also push new bib commands).<span class=""><br>
<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>One of the downsides of SIIT is that this
"predetermination" of<br>
address mappings is not going to be friendly with your "Every
IPv6<br>
device has a somewhat unpredictable IP where the prefix is<br>
fg01::/64" requirement.<br>
<br>
You can either find a way to impose more order to your address<br>
assignment policies (so they will be friendlier to SIIT's<br>
constraints) </div>
</div>
</blockquote></span>
Yes, this is why I can't use SIIT. I can't impose more constraints
on the IP of these devices...<span class=""><br>
<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>or you can try Taiga (<a href="http://www.litech.org/tayga/" target="_blank">http://www.litech.org/tayga/</a>).<br>
Tayga is a SIIT/NAT64 hybrid in that it can assign v4
addresses to<br>
IPv6 nodes on the fly, and then the entire address (not just
an<br>
address and port) are assigned to the IPv6 node. I can't vouch
for<br>
Tayga because I don't use it and hasn't received updates in a
long<br>
time, but perhaps you can squeeze something out of it.<br>
</div>
</div>
</blockquote></span>
I tried it! But it doesn't compile out of the box for kernel 4.1.15.
I didn't have time to investigate where the problem comes from.<span class=""><br>
<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
Alternatively, you might want to open this hybrid operation
mode as<br>
a feature request for Jool: <a href="https://github.com/NICMx/Jool/issues" target="_blank">https://github.com/NICMx/Jool/issues</a><br>
</div>
</div>
</blockquote></span>
That's an idea! I'll try and define more precisely the expected
behavior before putting it up in Github.<span class=""><br>
<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>> Here, I reckon that the gateway does not know that
packets on the<br>
> network with the 192.168.0.54 address are in fact
destined to<br>
> her, because when I manually add this IP to eth0 (with ip
addr<br>
> add <a href="http://192.168.0.54/24" target="_blank">192.168.0.54/24</a> dev eth0
), suddenly, it works!<br>
<br>
A NAT64 is a device that masks IPv6 nodes behind it using its
own<br>
IPv4 address (or addresses).<br>
An SIIT is a device that renames your IPv6 nodes, each using a<br>
separate IPv4 address, without them realizing it.<br>
<br>
Pay special attention to the part where I say "using its own
IPv4<br>
address". NAT64 does not rename v6 nodes like SIIT does; it<br>
pretends it itself is the IPv6 nodes it is masking. That's why
they<br>
are called "masks" :)<br>
<br>
So yes; the v4 nodes need to be fooled into thinking that G64
*is*<br>
the v6 network. One way to do that is by adding the addresses
to<br>
G64's interface. (So G64 answers ARP "neighbor" requests to
these<br>
packets.)<br>
<br>
</div>
</div>
</blockquote></span>
Yes, I got that. But then, when we define a pool4, it stops doing
this when it maps an IPv6 traffic to an IPv4. Or maybe I don't
understand the use of pool4?<span class=""><br>
<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>> How can I tell my eth0 interface that its should be
concerned by<br>
packets adressed on the 192.168.0.54 (which it used to send
packets<br>
beforehand since pinging worked), but without statically<br>
configuring it with this IP address?<br>
<br>
You need to realize that 192.168.0.54 belongs to C4's network<br>
(<a href="http://192.168.0.54/100" target="_blank">192.168.0.54/100</a>),
so C4 is expecting .54 to be one of its<br>
neighbors. For this reason, it doesn't intend to send the
packet<br>
via any gateways.<br>
</div>
</div>
</blockquote></span>
Agreed, but I think the problem comes from G64 that does not know
that indeed .54 traffic is expected to be for it (more specifically
for one of its services).<span class=""><br>
<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>That said, you can always instead inform C4 that any
traffic<br>
towards 192.168.0.54 should be routed via G64:<br>
<br>
romain@c4$ ip route add <a href="http://192.168.0.54/32" target="_blank">192.168.0.54/32</a> via
192.168.0.100<br>
<br>
But perhaps by this point you have realized that you should
more<br>
likely redesign the setup :p<br>
</div>
</div>
</blockquote></span>
Yes, and this is something I would like to avoid.<span class=""><br>
<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>> Can jool automatically and dynamically requests a new
IPv4 from a<br>
DHCP server for an IPv6 device hidden behind?<br>
<br>
No, but why would you want to do that? (maybe I'm missing<br>
something)<br>
</div>
</div>
</blockquote></span>
I explained in the beginning of this email why I want this.<span class=""><br>
<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>> Can jool automatically set up new address on the eth0
interface<br>
(when they are allocated by the DHCP server)?<br>
<br>
No, but can't a shell script do it?<br>
</div>
</div>
</blockquote></span>
It definitely could! I think Michael's proposal is quite
interesting, I'll start playing with macvlan to see how it behaves
with the dhcp and everything.<span class=""><br>
<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
By the way: It seems that you're having trouble understanding
these<br>
concepts from the documentation. Any tips on how to improve
it?<br>
</div>
</div>
</blockquote></span>
I don't yet. I think that when I have better grasp on all those
things I will be able to find areas that can be improved (if there
are any).<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
<br>
<br>
Romain Bazile<br>
<br>
</font></span></div>
</blockquote></div><br></div>