30 Apr
2017
30 Apr
'17
12:36 p.m.
Jehan,
Precisely what problem you are you trying to solve?
Alex
2017-04-30 11:54 GMT-07:00 Jehan Tremback <jehan.tremback(a)gmail.com>om>:
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(a)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(a)gmail.com>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 <jake(a)spaz.org>rg>:
_______________________________________________
mesh mailing list
mesh(a)lists.sudoroom.org
https://sudoroom.org/lists/listinfo/mesh
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