I noticed a few errors: > Otherwise A6 would be the only IPv4 node > able to talk to the IPv4 network.
Should read > Otherwise A6 would be the only IPv6 node > able to talk to the IPv4 network. And also > 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. Should read > You need to realize that 192.168.0.54 belongs to C4's network > (192.168.0.0/24), so C4 is expecting .54 to be one of its > neighbors. On Thu, Jul 28, 2016 at 4:46 PM, Alberto Leiva <[email protected]> wrote: > 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@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 <[email protected]> > 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 [ >> ] [email protected] http://www.sandelman.ca/ | ruby on >> rails [ >> >> >> _______________________________________________ >> Jool-list mailing list >> [email protected] >> https://mail-lists.nic.mx/listas/listinfo/jool-list >> >> >
_______________________________________________ Jool-list mailing list [email protected] https://mail-lists.nic.mx/listas/listinfo/jool-list
