<div dir="ltr">I noticed a few errors:<br><br>> Otherwise A6 would be the only IPv4 node<br>> able to talk to the IPv4 network.<br><br>Should read<br><br>> Otherwise A6 would be the only IPv6 node<br>> able to talk to the IPv4 network.<br><br>And also<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">192.168.0.54/100</a>), so C4 is expecting .54 to be one of its<br>> neighbors.<br><br>Should read<br><br>> You need to realize that 192.168.0.54 belongs to C4's network<br>> (<a href="http://192.168.0.0/24">192.168.0.0/24</a>), so C4 is expecting .54 to be one of its<br>> neighbors.<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 28, 2016 at 4:46 PM, Alberto Leiva <span dir="ltr"><<a href="mailto:ydahhrk@gmail.com" target="_blank">ydahhrk@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hello, guys<br><br></div>Well, I have a lot to say :)<br><div><span class=""><br>> I load jool with an IPv6 pool (with jool -6 -a fg01::/96 ). When<br>> I try to ping from A6 to C4, I have a correct ping (dmesg shows a<br>> session was put up: Added session<br>> fg01::3e52:10b1:6fc8:f0f1:94f8#1|fg01::c0a8:c0#1|192.168.0.100#62153|192.168.0.192#62153|ICMP).<br>> This behavior is nice, but I'm not able to send back packets,<br>> even if I start a UDP session from A6. I should be able to send<br>> packets to <a href="http://192.168.0.100:64065" target="_blank">192.168.0.100:64065</a> for example, but they are not<br>> received by A6.<br><br></span>This is normal; it is a core nuance of the (Stateful) NAT64 design.<br>Let me explain:<br><br>When A6 sends a packet, G64 creates a mapping for it, and remembers<br>it so it can handle the response:<br><br>- A6 pings packet fg01::<blahblah>:94f8#1 -> fg01::c0a8:c0#1.<br>- G64 looks at pool4 and decides 192.168.0.100#62153 is a suitable<br>  ICMP mask for fg01::<blahblah>:94f8#1.<br>  It then translates the packet into 192.168.0.100#62153 -><br>  192.168.0.192#62153 and (very important) remembers the<br>  [192.168.0.100#62153 fg01::<blahblah>:94f8#1] mask.<br>- C4 answers using packet 192.168.0.192#62153 -><br>  192.168.0.100#62153.<br>- G64 realizes that the destination address of the packet matches<br>  one of its masks, and looking at this mask, it realizes that C4's<br>  packet is intended for fg01::<blahblah>:94f8#1. So it translates<br>  the packet and the ping succeeds.<br><br>On the other hand, this is what's happening to your UDP packet:<br><br>- C4 writes (for example) packet <a href="http://192.168.0.104:12345" target="_blank">192.168.0.104:12345</a> -><br>  192.168.0.100#64065.<br>- G64 does not have a mapping for 192.168.0.100#64065, so it<br>  doesn't know where it is headed. Therefore, it doesn't know how<br>  to translate the packet.<br><br>Why can G64 infer a mapping for an IPv6 packet but not for an IPv4<br>one? because any source v6 address can be translated as any pool4<br>address, and any destination v6 address can be translated by<br>removing the pool6 prefix. On the other hand, while a source v4<br>address can be translated by adding the pool6 prefix, there is no<br>way to translate a v4 destination address without an already<br>existing mapping. Think about it: You are masking 20-255 nodes<br>using just G64's address (192.168.0.100). The fact that you<br>already have a mapping that says that 192.168.0.100#62153 is<br>fg01::<blahblah>:94f8#1, you can't automatically assume that any<br>packet towards 192.168.0.100 should be headed towards<br>fg01::<blahblah>:94f8. Otherwise A6 would be the only IPv4 node<br>able to talk to the IPv4 network.<br><br>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><br>(Protip: Just for the sake of clarity, documentation labels these<br>mappings "BIB entries". They are most of the time all you need to<br>pay attention to; sessions are fairly useless from a user<br>standpoint.)<span class=""><br><br>> Moreover, this is not the desired behavior as I want A6 to have<br>> its own IPv4 address (to make it easier to talk to it).<br><br></span>This is exactly what SIIT does; it lets you predetermine an IPv4<br>address for each of your IPv6 nodes. This means it frees you from<br>the disadvantages of the BIB entries (and advantages, of course.)<br><br>One of the downsides of SIIT is that this "predetermination" of<br>address mappings is not going to be friendly with your "Every IPv6<span class=""><br>device has a somewhat unpredictable IP where the prefix is<br></span>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) 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><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><span class=""><br><br>> 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></span>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.)<span class=""><br><br>> Is it normal behavior that I cannot send back UDP packets to the<br>NATed IPv4:port, even when the session has been correctly added?<br>(I'm talking about a real UDP session, not an ICMP one)<br><br></span>Yes. If v4-started traffic is one of your basic requirements, you<br>need to either meddle with static BIB entries or switch over to<br>SIIT.<span class=""><br><br>> 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></span>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><br>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<span class=""><br><br>> Can jool automatically and dynamically requests a new IPv4 from a<br>DHCP server for an IPv6 device hidden behind?<br><br></span>No, but why would you want to do that? (maybe I'm missing<br>something)<span class=""><br><br>> Can jool automatically set up new address on the eth0 interface<br>(when they are allocated by the DHCP server)?<br><br></span>No, but can't a shell script do it?<br><br><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><br>Alberto<br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Thu, Jul 28, 2016 at 3:33 PM, Michael Richardson <span dir="ltr"><<a href="mailto:mcr@sandelman.ca" target="_blank">mcr@sandelman.ca</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><br>
Hi,<br>
What you are doing will become more and more common.<br>
<br>
Jool historically has needed an IP address different than the one on it's<br>
primary interface.  I've made this work (including getting the IP from<br>
DHCPv4) using clone a macvlan interface, and some custom dhclient-up<br>
scripts.<br>
<br>
That will take care of your needs:<br>
<br>
>* Can jool automatically and dynamically requests a new IPv4 from a<br>
<span>>  DHCP server for an IPv6 device hidden behind?<br>
</span>>* Can jool automatically set up new address on the eth0 interface<br>
<span>>  (when they are allocated by the DHCP server)?<br>
<br>
</span>SIIT would let you embed IPv4 into your v6 network, which would also work.<br>
<br>
--<br>
]               Never tell me the odds!                 | ipv6 mesh networks [<br>
]   Michael Richardson, Sandelman Software Works        | network architect  [<br>
]     <a href="mailto:mcr@sandelman.ca" target="_blank">mcr@sandelman.ca</a>  <a href="http://www.sandelman.ca/" rel="noreferrer" target="_blank">http://www.sandelman.ca/</a>        |   ruby on rails    [<br>
<br>
<br></div></div>_______________________________________________<br>
Jool-list mailing list<br>
<a href="mailto:Jool-list@nic.mx" target="_blank">Jool-list@nic.mx</a><br>
<a href="https://mail-lists.nic.mx/listas/listinfo/jool-list" rel="noreferrer" target="_blank">https://mail-lists.nic.mx/listas/listinfo/jool-list</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div>