After doing some research I found RFC 7596, Lightweight 4over6. I believe this is the current best practice for running ipv6 without affecting protocols and devices that can't handle it. I'm not sure on the details but I think this is used a lot in China.

This would involve a software component on the exit server called the "AFTR" and a component on the home node called the "B4" (they really reached pretty far on their acronyms). 

The AFTR provisions each home node with a public IP and port range which it is allowed to use. The B4 gives ipv4 client devices private IPs and NATs their packets to its public IP and port range. After NATing, the packets are encapsulated in an ipv6 packet and sent to the AFTR. The AFTR then decapsulates them and sends them on their way. This basically happens kind of in reverse on the way back.

The B4 also has a DNS proxy and there are some other details that you can read about if you are interested. Openwrt barrier breaker claims to have experimental support for this standard.

-Jehan

On Sun, Apr 30, 2017 at 2:42 PM, Jehan Tremback <jehan.tremback@gmail.com> wrote:
This is mostly academic, and I'm not suggesting we do any of this on the mesh any time soon. I was just trying to think about ways that nodes could self-assign ip addresses. One way would be to switch to a larger ipv6 address space so that collisions wouldn't be a problem. Clearly, this solution is way more complex than just continuing to use a centralized makenode process. I'm mostly just idly speculating.

-jehan

On Sun, Apr 30, 2017 at 12:36 PM, Alexander Papazoglou <papazoga@gmail.com> wrote:
Jehan,

Precisely what problem you are you trying to solve?

Alex


2017-04-30 11:54 GMT-07:00 Jehan Tremback <jehan.tremback@gmail.com>:
Fascinating discussion, it's really helping me see firsthand why ipv6 is taking 15+ years to phase in.

What about this: We totally separate the ipv4 and ipv6 parts of this scheme. The ipv6 mesh is considered as a totally foreign transport and serves only to create a tunnel from the client to the exit server. The exit server does all DHCP for the clients over these tunnels. The ipv6 section of the network is like an ethernet cable, and l2tp or something in the home node creates a virtual interface over which the clients connecting to the home node talk to the exit server. I might be totally off base here, or just rehashing something was already covered, but would something like that work?

-Jehan

On Sat, Apr 29, 2017 at 1:53 PM, Alexander Papazoglou <papazoga@gmail.com> wrote:
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 <papazoga@gmail.com>:
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 <jake@spaz.org>:
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@lists.sudoroom.org
https://sudoroom.org/lists/listinfo/mesh



_______________________________________________
mesh mailing list
mesh@lists.sudoroom.org
https://sudoroom.org/lists/listinfo/mesh