[Jool-list] Jool use with IPv6 island connected to IPv4 network

[Romain Bazile]

Hi,


First of all, thanks for the answers!

Regarding your comments, it looks I did not made myself very clear! I 
answered below.


> This property of remembering mappings is what makes NAT64
> "stateful". Its advantage is that you're using a few G64 addresses
> to grant a potentially large and dynamic number of IPv6 nodes
> access to IPv4 ones. The drawback is that IPv4 nodes cannot start
> communication with v6 ones because G64 doesn't initially know who
> they are talking to.
>
> (Unless you predefine mappings yourself. You can find more
> information at https://jool.mx/en/bib.html and
> https://jool.mx/en/usr-flags-bib.html)
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).
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.

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).


> One of the downsides of SIIT is that this "predetermination" of
> address mappings is not going to be friendly with your "Every IPv6
> device has a somewhat unpredictable IP where the prefix is
> fg01::/64" requirement.
>
> You can either find a way to impose more order to your address
> assignment policies (so they will be friendlier to SIIT's
> constraints)
Yes, this is why I can't use SIIT. I can't impose more constraints on 
the IP of these devices...


> or you can try Taiga (http://www.litech.org/tayga/).
> Tayga is a SIIT/NAT64 hybrid in that it can assign v4 addresses to
> IPv6 nodes on the fly, and then the entire address (not just an
> address and port) are assigned to the IPv6 node. I can't vouch for
> Tayga because I don't use it and hasn't received updates in a long
> time, but perhaps you can squeeze something out of it.
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.


>
> Alternatively, you might want to open this hybrid operation mode as
> a feature request for Jool: https://github.com/NICMx/Jool/issues
That's an idea! I'll try and define more precisely the expected behavior 
before putting it up in Github.


> > Here, I reckon that the gateway does not know that packets on the
> > network with the 192.168.0.54 address are in fact destined to
> > her, because when I manually add this IP to eth0 (with ip addr
> > add 192.168.0.54/24 <http://192.168.0.54/24> dev eth0 ), suddenly, 
> it works!
>
> A NAT64 is a device that masks IPv6 nodes behind it using its own
> IPv4 address (or addresses).
> An SIIT is a device that renames your IPv6 nodes, each using a
> separate IPv4 address, without them realizing it.
>
> Pay special attention to the part where I say "using its own IPv4
> address". NAT64 does not rename v6 nodes like SIIT does; it
> pretends it itself is the IPv6 nodes it is masking. That's why they
> are called "masks" :)
>
> So yes; the v4 nodes need to be fooled into thinking that G64 *is*
> the v6 network. One way to do that is by adding the addresses to
> G64's interface. (So G64 answers ARP "neighbor" requests to these
> packets.)
>
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?


> > How can I tell my eth0 interface that its should be concerned by
> packets adressed on the 192.168.0.54 (which it used to send packets
> beforehand since pinging worked), but without statically
> configuring it with this IP address?
>
> You need to realize that 192.168.0.54 belongs to C4's network
> (192.168.0.54/100 <http://192.168.0.54/100>), so C4 is expecting .54 
> to be one of its
> neighbors. For this reason, it doesn't intend to send the packet
> via any gateways.
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).


> That said, you can always instead inform C4 that any traffic
> towards 192.168.0.54 should be routed via G64:
>
>     romain at c4$ ip route add 192.168.0.54/32 <http://192.168.0.54/32> 
> via 192.168.0.100
>
> But perhaps by this point you have realized that you should more
> likely redesign the setup :p
Yes, and this is something I would like to avoid.


> > Can jool automatically and dynamically requests a new IPv4 from a
> DHCP server for an IPv6 device hidden behind?
>
> No, but why would you want to do that? (maybe I'm missing
> something)
I explained in the beginning of this email why I want this.


> > Can jool automatically set up new address on the eth0 interface
> (when they are allocated by the DHCP server)?
>
> No, but can't a shell script do it?
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.


>
> By the way: It seems that you're having trouble understanding these
> concepts from the documentation. Any tips on how to improve it?
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).




Romain Bazile

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail-lists.nic.mx/pipermail/jool-list/attachments/20160729/cb11714d/attachment.html>