the network knows how to get return traffic back to any given client? Wouldn't giving clients ipv6 addresses result in the problems with many of the ipv4 only protocols that were mentioned at the start of the thread? Yes if we give them only IPv6 addresses but we want them to have both.

So let me get this straight- home nodes advertise their /26, which is >> how >> the network knows how to get return traffic back to any given client? >> >> Wouldn't giving clients ipv6 addresses result in the problems with >> many of >> the ipv4 only protocols that were mentioned at the start of the >> thread? >> >> >> Yes if we give them only IPv6 addresses but we want them to have both. > but if the mesh relied on IPV6 for everything, then couldn't the home nodes do IPV4 masquerading to IPV6 and they wouldn't need their own /26 because you could have identical IPV4 addresses on different home nodes that way? meaning, the IPV4 address given by DHCP by a home node is only for that node to talk to that client, and everything goes out over IPV6 from node to node and to the exit node (where it does reverse masquerading to the internet for IPV4 traffic) does this make sense? i know it would be a lot of work but maybe it's a good path forward.. and it simplifies some things, for example no more need to coordinate 100./26 IPV4 subnets between home nodes... you could use the home node's MAC address for its IPV6 subnet. -jake _______________________________________________ mesh mailing list mesh(a)lists.sudoroom.org https://sudoroom.org/lists/listinfo/mesh

And also, as Marc pointed out, there's the very real potential of headaches with conntrack and SSL. Alex 2017-04-29 13:38 GMT-07:00 Alexander Papazoglou &lt;papazoga(a)gmail.com&gt;om>: > Jake, > > If I understand you correctly, you're saying that an IPv4-only client > communicates to the internet like this: > > client <--------------> homenode <-----------> exitserver > <---------------> internet > IPv4 packet routed through IPv6 > packet > gets NAT64ed mesh (IPv6) gets > reverse-NAT64ed > (both SNAT again > (both SNAT and > and DNAT) DNAT). > > Let's assume the client is assigned 1.1.1.2, and is trying to send a > packet to 4.4.4.4 (on the internet). Then the first NAT > stage is stateless. The source address gets prefixed by the homenode's > prefix (to, say h::1:1:1:2) and the destination > address gets the "internet" prefix (to say, i::4:4:4:4). The mesh > routing ensures that the packet arrives at the exit server, > which now performs *stateful* NAT64 (RFC6146?) on the source address, > and stateless on the destination (removing > the i:: prefix). > > This can all work (and was briefly considered in the past). The > problem is the implementation state of the various parts. > Does OpenWRT support stateful NAT64? > > Alex > > > > 2017-04-29 12:21 GMT-07:00 Jake &lt;jake(a)spaz.org&gt;rg>: > >> So let me get this straight- home nodes advertise their /26, which is >>>> how >>>> the network knows how to get return traffic back to any given >>>> client? >>>> >>>> Wouldn't giving clients ipv6 addresses result in the problems with >>>> many of >>>> the ipv4 only protocols that were mentioned at the start of the >>>> thread? >>>> >>>> >>>> Yes if we give them only IPv6 addresses but we want them to have >>> both. >>> >> >> but if the mesh relied on IPV6 for everything, then couldn't the home >> nodes do >> IPV4 masquerading to IPV6 and they wouldn't need their own /26 >> because you >> could have identical IPV4 addresses on different home nodes that way? >> >> meaning, the IPV4 address given by DHCP by a home node is only for >> that node to >> talk to that client, and everything goes out over IPV6 from node to >> node and to >> the exit node (where it does reverse masquerading to the internet for >> IPV4 >> traffic) >> >> does this make sense? i know it would be a lot of work but maybe >> it's a good >> path forward.. and it simplifies some things, for example no more >> need to >> coordinate 100./26 IPV4 subnets between home nodes... you could use >> the home >> node's MAC address for its IPV6 subnet. >> >> -jake >> >> _______________________________________________ >> mesh mailing list >> mesh(a)lists.sudoroom.org >> https://sudoroom.org/lists/listinfo/mesh >> > > _______________________________________________ mesh mailing list mesh(a)lists.sudoroom.org https://sudoroom.org/lists/listinfo/mesh