[Jool-list] Jool use with IPv6 island connected to IPv4 network
Alberto Leiva
ydahhrk at gmail.com
Thu Jul 28 16:46:16 CDT 2016
Hello, guys
Well, I have a lot to say :)
> I load jool with an IPv6 pool (with jool -6 -a fg01::/96 ). When
> I try to ping from A6 to C4, I have a correct ping (dmesg shows a
> session was put up: Added session
>
fg01::3e52:10b1:6fc8:f0f1:94f8#1|fg01::c0a8:c0#1|192.168.0.100#62153|192.168.0.192#62153|ICMP).
> This behavior is nice, but I'm not able to send back packets,
> even if I start a UDP session from A6. I should be able to send
> packets to 192.168.0.100:64065 for example, but they are not
> received by A6.
This is normal; it is a core nuance of the (Stateful) NAT64 design.
Let me explain:
When A6 sends a packet, G64 creates a mapping for it, and remembers
it so it can handle the response:
- A6 pings packet fg01::<blahblah>:94f8#1 -> fg01::c0a8:c0#1.
- G64 looks at pool4 and decides 192.168.0.100#62153 is a suitable
ICMP mask for fg01::<blahblah>:94f8#1.
It then translates the packet into 192.168.0.100#62153 ->
192.168.0.192#62153 and (very important) remembers the
[192.168.0.100#62153 fg01::<blahblah>:94f8#1] mask.
- C4 answers using packet 192.168.0.192#62153 ->
192.168.0.100#62153.
- G64 realizes that the destination address of the packet matches
one of its masks, and looking at this mask, it realizes that C4's
packet is intended for fg01::<blahblah>:94f8#1. So it translates
the packet and the ping succeeds.
On the other hand, this is what's happening to your UDP packet:
- C4 writes (for example) packet 192.168.0.104:12345 ->
192.168.0.100#64065.
- G64 does not have a mapping for 192.168.0.100#64065, so it
doesn't know where it is headed. Therefore, it doesn't know how
to translate the packet.
Why can G64 infer a mapping for an IPv6 packet but not for an IPv4
one? because any source v6 address can be translated as any pool4
address, and any destination v6 address can be translated by
removing the pool6 prefix. On the other hand, while a source v4
address can be translated by adding the pool6 prefix, there is no
way to translate a v4 destination address without an already
existing mapping. Think about it: You are masking 20-255 nodes
using just G64's address (192.168.0.100). The fact that you
already have a mapping that says that 192.168.0.100#62153 is
fg01::<blahblah>:94f8#1, you can't automatically assume that any
packet towards 192.168.0.100 should be headed towards
fg01::<blahblah>:94f8. Otherwise A6 would be the only IPv4 node
able to talk to the IPv4 network.
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)
(Protip: Just for the sake of clarity, documentation labels these
mappings "BIB entries". They are most of the time all you need to
pay attention to; sessions are fairly useless from a user
standpoint.)
> Moreover, this is not the desired behavior as I want A6 to have
> its own IPv4 address (to make it easier to talk to it).
This is exactly what SIIT does; it lets you predetermine an IPv4
address for each of your IPv6 nodes. This means it frees you from
the disadvantages of the BIB entries (and advantages, of course.)
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) 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.
Alternatively, you might want to open this hybrid operation mode as
a feature request for Jool: https://github.com/NICMx/Jool/issues
> 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 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.)
> Is it normal behavior that I cannot send back UDP packets to the
NATed IPv4:port, even when the session has been correctly added?
(I'm talking about a real UDP session, not an ICMP one)
Yes. If v4-started traffic is one of your basic requirements, you
need to either meddle with static BIB entries or switch over to
SIIT.
> 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), 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.
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 via 192.168.0.100
But perhaps by this point you have realized that you should more
likely redesign the setup :p
> 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)
> 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?
By the way: It seems that you're having trouble understanding these
concepts from the documentation. Any tips on how to improve it?
Alberto
On Thu, Jul 28, 2016 at 3:33 PM, Michael Richardson <mcr at sandelman.ca>
wrote:
>
> Hi,
> What you are doing will become more and more common.
>
> Jool historically has needed an IP address different than the one on it's
> primary interface. I've made this work (including getting the IP from
> DHCPv4) using clone a macvlan interface, and some custom dhclient-up
> scripts.
>
> That will take care of your needs:
>
> >* Can jool automatically and dynamically requests a new IPv4 from a
> > DHCP server for an IPv6 device hidden behind?
> >* Can jool automatically set up new address on the eth0 interface
> > (when they are allocated by the DHCP server)?
>
> SIIT would let you embed IPv4 into your v6 network, which would also work.
>
> --
> ] Never tell me the odds! | ipv6 mesh
> networks [
> ] Michael Richardson, Sandelman Software Works | network
> architect [
> ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on
> rails [
>
>
> _______________________________________________
> Jool-list mailing list
> Jool-list at nic.mx
> https://mail-lists.nic.mx/listas/listinfo/jool-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail-lists.nic.mx/pipermail/jool-list/attachments/20160728/e0702152/attachment.html>
More information about the Jool-list
mailing list