[Jool-list] Jool use with IPv6 island connected to IPv4 network
Alberto Leiva
ydahhrk at gmail.com
Thu Jul 28 17:12:29 CDT 2016
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 <ydahhrk at gmail.com> 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 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/a8a05efa/attachment-0001.html>
More information about the Jool-list
mailing list