27 Apr
2017
27 Apr
'17
4:52 a.m.
We should figure out how to apply for IPv6 space.
Who wants to take this on?
--
marc/juul
27 Apr
27 Apr
9:12 a.m.
IMO, we should put everything on ipv6 randomly generated link-local
addresses to avoid the whole makenode centralized IP assignment business.
On Thu, Apr 27, 2017 at 4:52 AM, Marc Juul <juul(a)labitat.dk> wrote:
We should figure out how to apply for IPv6 space.
Who wants to take this on?
--
marc/juul
_______________________________________________
mesh mailing list
mesh(a)lists.sudoroom.org
https://sudoroom.org/lists/listinfo/mesh
9:17 a.m.
On Thu, Apr 27, 2017 at 9:12 AM, Jehan Tremback <jehan.tremback(a)gmail.com>
wrote:
IMO, we should put everything on ipv6 randomly
generated link-local
addresses to avoid the whole makenode centralized IP assignment business.
We cannot avoid using IPv4. Most of the internet is still IPv4 only and
IPv6 to IPv4 gateways are problematic.
On Thu, Apr 27, 2017 at 4:52 AM, Marc Juul <juul(a)labitat.dk> wrote:
We should figure out how to apply for IPv6
space.
Who wants to take this on?
--
marc/juul
_______________________________________________
mesh mailing list
mesh(a)lists.sudoroom.org
https://sudoroom.org/lists/listinfo/mesh
9:27 a.m.
It seems like something that would be easy, just NAT ipv4 traffic to IPv6
for our network. Can you link to any resources on these difficulties?
-Jehan
On Thu, Apr 27, 2017 at 9:17 AM, Marc Juul <juul(a)labitat.dk> wrote:
On Thu, Apr 27, 2017 at 9:12 AM, Jehan Tremback <jehan.tremback(a)gmail.com>
wrote:
IMO, we should put everything on ipv6 randomly
generated link-local
addresses to avoid the whole makenode centralized IP assignment business.
We cannot avoid using IPv4. Most of the internet is still IPv4 only and
IPv6 to IPv4 gateways are problematic.
On Thu, Apr 27, 2017 at 4:52 AM, Marc Juul <juul(a)labitat.dk> wrote:
We should figure out how to apply for IPv6
space.
Who wants to take this on?
--
marc/juul
_______________________________________________
mesh mailing list
mesh(a)lists.sudoroom.org
https://sudoroom.org/lists/listinfo/mesh
9:48 a.m.
On Thu, Apr 27, 2017 at 9:27 AM, Jehan Tremback <jehan.tremback(a)gmail.com>
wrote:
It seems like something that would be easy, just NAT
ipv4 traffic to IPv6
for our network. Can you link to any resources on these difficulties?
"Not every type of resource is accessible with NAT64. Protocols that embed
IPv4 literal addresses, such as SIP
<https://en.wikipedia.org/wiki/Session_Initiation_Protocol> and SDP
<https://en.wikipedia.org/wiki/Session_Description_Protocol>, FTP
<https://en.wikipedia.org/wiki/FTP>, WebSocket
<https://en.wikipedia.org/wiki/WebSocket>, Skype
<https://en.wikipedia.org/wiki/Skype>, MSN, and any other content with IPv4
literals are excluded"
https://en.wikipedia.org/wiki/NAT64
"There are two noticeable issues with this transition mechanism:
- It only works for cases where DNS is used to find the remote host
address, if IPv4 literals are used the DNS64 server will never be involved.
- Because the DNS64 server needs to return records not specified by the
domain owner, DNSSEC <https://en.wikipedia.org/wiki/DNSSEC> validation
against the root
<https://en.wikipedia.org/wiki/DNSSEC#Deployment_at_the_DNS_root> will
fail in cases where the DNS server doing the translation is not the domain
owner's server. "
https://en.wikipedia.org/wiki/IPv6_transition_mechanism#DNS64
--
marc/juul
11:03 a.m.
Hypothetically, what if tunnels are opened from the exit server to the home
node carrying ipv4 over ipv6? Obviously this could be a lot of
implementation work.
-Jehan
On Thu, Apr 27, 2017 at 9:48 AM, Marc Juul <juul(a)labitat.dk> wrote:
On Thu, Apr 27, 2017 at 9:27 AM, Jehan Tremback <jehan.tremback(a)gmail.com>
wrote:
It seems like something that would be easy, just
NAT ipv4 traffic to IPv6
for our network. Can you link to any resources on these difficulties?
"Not every type of resource is accessible with NAT64. Protocols that embed
IPv4 literal addresses, such as SIP
<https://en.wikipedia.org/wiki/Session_Initiation_Protocol> and SDP
<https://en.wikipedia.org/wiki/Session_Description_Protocol>, FTP
<https://en.wikipedia.org/wiki/FTP>, WebSocket
<https://en.wikipedia.org/wiki/WebSocket>, Skype
<https://en.wikipedia.org/wiki/Skype>, MSN, and any other content with
IPv4 literals are excluded"
https://en.wikipedia.org/wiki/NAT64
"There are two noticeable issues with this transition mechanism:
- It only works for cases where DNS is used to find the remote host
address, if IPv4 literals are used the DNS64 server will never be involved.
- Because the DNS64 server needs to return records not specified by
the domain owner, DNSSEC <https://en.wikipedia.org/wiki/DNSSEC>
validation against the root
<https://en.wikipedia.org/wiki/DNSSEC#Deployment_at_the_DNS_root> will
fail in cases where the DNS server doing the translation is not the domain
owner's server. "
https://en.wikipedia.org/wiki/IPv6_transition_mechanism#DNS64
--
marc/juul
12:18 p.m.
On Thu, Apr 27, 2017 at 11:03 AM, Jehan Tremback <jehan.tremback(a)gmail.com>
wrote:
Hypothetically, what if tunnels are opened from the
exit server to the
home node carrying ipv4 over ipv6? Obviously this could be a lot of
implementation work.
You would still have to assign all clients unique IPv4 addresses so hmm...
it's not impossible but i can't think of a way it wouldn't make our lives
worse.
1:22 p.m.
Hi!
IMO, we should put everything on ipv6 randomly
generated link-local
addresses to avoid the whole makenode centralized IP assignment business.
And how would you route that over L3 network?
It would work over L2 Batman network. But not over L3.
Have you looked into AHCP:
https://www.irif.fr/~jch/software/ahcp/
Mitar
--
http://mitar.tnode.com/
https://twitter.com/mitar_m
1:28 p.m.
On Thu, Apr 27, 2017 at 1:22 PM, Mitar <mitar(a)tnode.com> wrote:
Hi!
Ssssh! Why did you have to tell them about AHCP?
... *OBLIVIATE!*
--
marc/juul
IMO, we should put everything on ipv6 randomly
generated link-local
addresses to avoid the whole makenode centralized IP assignment business.
And how would you route that over L3 network?
It would work over L2 Batman network. But not over L3.
Have you looked into AHCP:
https://www.irif.fr/~jch/software/ahcp/
7:27 p.m.
And how would you route that over L3 network?
Off the top of my head:
- Packet headed somewhere on the internet with an ipv4 address comes from a
client device to the home node.
- Home node pops that packet into an ipv6 packet bearing the ipv6 address
of the exit server which is then routed over the mesh network
- Exit server takes the ipv4 packet out and does NAT on it (switches the
source address to public IP) and sends it out to the internet.
- Response from internet comes back to exit server, the exit server does
NAT again (switches the destination address to private IP)
- Exit server puts the packet into an ipv6 packet with the ipv6 address of
the home node and sends it onto the mesh (it needs to have kept track of
the ipv6 address)
- Home node receives the ipv6 packet, takes the ipv4 packet out and sends
it to the client.
I'm not an expert, so there might be some issues with this. Here's an RFC
which might be similar:
https://tools.ietf.org/html/rfc7040
On Thu, Apr 27, 2017 at 1:28 PM, Marc Juul <juul(a)labitat.dk> wrote:
>
>
> On Thu, Apr 27, 2017 at 1:22 PM, Mitar <mitar(a)tnode.com> wrote:
>
>> Hi!
>>
>> > IMO, we should put everything on ipv6 randomly generated link-local
>> > addresses to avoid the whole makenode centralized IP assignment
>> business.
>>
> And how would you route that over L3 network?
>>
>> It would work over L2 Batman network. But not over L3.
>>
>> Have you looked into AHCP:
>>
>> https://www.irif.fr/~jch/software/ahcp/
>
>
> Ssssh! Why did you have to tell them about AHCP?
>
> ... *OBLIVIATE!*
>
> --
> marc/juul
>
7:50 p.m.
Hi!
I was asking for the "IPv6 randomly generated link-local
addresses" idea. How would that route?
Mitar
--
http://mitar.tnode.com/
https://twitter.com/mitar_m
And how would
you route that over L3 network?
Off the top of my head:
- Packet headed somewhere on the internet with an ipv4 address comes from a
client device to the home node.
- Home node pops that packet into an ipv6 packet bearing the ipv6 address
of the exit server which is then routed over the mesh network
- Exit server takes the ipv4 packet out and does NAT on it (switches the
source address to public IP) and sends it out to the internet.
- Response from internet comes back to exit server, the exit server does
NAT again (switches the destination address to private IP)
- Exit server puts the packet into an ipv6 packet with the ipv6 address of
the home node and sends it onto the mesh (it needs to have kept track of
the ipv6 address)
- Home node receives the ipv6 packet, takes the ipv4 packet out and sends
it to the client.
I'm not an expert, so there might be some issues with this. Here's an RFC
which might be similar:
https://tools.ietf.org/html/rfc7040
On Thu, Apr 27, 2017 at 1:28 PM, Marc Juul <juul(a)labitat.dk> wrote:
>
>
> On Thu, Apr 27, 2017 at 1:22 PM, Mitar <mitar(a)tnode.com> wrote:
>
>> Hi!
>>
>>> IMO, we should put everything on ipv6 randomly generated link-local
>>> addresses to avoid the whole makenode centralized IP assignment
>> business.
>>
> And how would you route that over L3 network?
>>
>> It would work over L2 Batman network. But not over L3.
>>
>> Have you looked into AHCP:
>>
>> https://www.irif.fr/~jch/software/ahcp/
>
>
> Ssssh! Why did you have to tell them about AHCP?
>
> ... *OBLIVIATE!*
>
> --
> marc/juul
>
8:34 p.m.
Well, I'm not an expert on all the details, but I imagine we'd generate
them randomly during makenode (or whenever). Then routes to addresses would
be propagated by babel in the same way that ipv4 addresses are now. I'm not
sure if the exit server would need an ipv6 address or if it would be good
to switch existing nodes over.
-Jehan
On Thu, Apr 27, 2017 at 7:50 PM, Mitar <mitar(a)tnode.com> wrote:
Hi!
I was asking for the "IPv6 randomly generated link-local
addresses" idea. How would that route?
Mitar
from a
And how
would you route that over L3 network?
Off the top of my head:
- Packet headed somewhere on the internet with an ipv4 address comes client device to the home node.
- Home node pops that packet into an ipv6 packet bearing the ipv6 address
of the exit server which is then routed over the mesh network
- Exit server takes the ipv4 packet out and does NAT on it (switches the
source address to public IP) and sends it out to the internet.
- Response from internet comes back to exit server, the exit server does
NAT again (switches the destination address to private IP)
- Exit server puts the packet into an ipv6 packet with the ipv6 address
of
the home node and sends it onto the mesh (it
needs to have kept track of
the ipv6 address)
- Home node receives the ipv6 packet, takes the ipv4 packet out and sends
it to the client.
I'm not an expert, so there might be some issues with this. Here's an RFC
which might be similar:
https://tools.ietf.org/html/rfc7040
On Thu, Apr 27, 2017 at 1:28 PM, Marc Juul <juul(a)labitat.dk> wrote:
--
http://mitar.tnode.com/
https://twitter.com/mitar_m
On Thu, Apr 27, 2017 at 1:22 PM, Mitar <mitar(a)tnode.com> wrote:
Hi!
> IMO, we should put everything on ipv6 randomly generated link-local
> addresses to avoid the whole makenode centralized IP assignment
business.
And how would you route that over L3 network?
It would work over L2 Batman network. But not over L3.
Have you looked into AHCP:
https://www.irif.fr/~jch/software/ahcp/
Ssssh! Why did you have to tell them about AHCP?
... *OBLIVIATE!*
--
marc/juul
8:44 p.m.
Hi!
Ah, for nodes. Yes, nodes could have automatic IPv6 addresses (and not
even link-local, but global).
For clients is trickier.
But we could do some automatic IPv6 address subnets for nodes. :-)
Mitar
Well, I'm not an expert on all the details, but I
imagine we'd generate
them randomly during makenode (or whenever). Then routes to addresses would
be propagated by babel in the same way that ipv4 addresses are now. I'm not
sure if the exit server would need an ipv6 address or if it would be good
to switch existing nodes over.
-Jehan
On Thu, Apr 27, 2017 at 7:50 PM, Mitar <mitar(a)tnode.com> wrote:
--
http://mitar.tnode.com/
https://twitter.com/mitar_m
Hi!
I was asking for the "IPv6 randomly generated link-local
addresses" idea. How would that route?
Mitar
from a
And how
would you route that over L3 network?
Off the top of my head:
- Packet headed somewhere on the internet with an ipv4 address comes client device to the home node.
- Home node pops that packet into an ipv6 packet bearing the ipv6 address
of the exit server which is then routed over the mesh network
- Exit server takes the ipv4 packet out and does NAT on it (switches the
source address to public IP) and sends it out to the internet.
- Response from internet comes back to exit server, the exit server does
NAT again (switches the destination address to private IP)
- Exit server puts the packet into an ipv6 packet with the ipv6 address
of
the home node and sends it onto the mesh (it
needs to have kept track of
the ipv6 address)
- Home node receives the ipv6 packet, takes the ipv4 packet out and sends
it to the client.
I'm not an expert, so there might be some issues with this. Here's an RFC
which might be similar:
https://tools.ietf.org/html/rfc7040
On Thu, Apr 27, 2017 at 1:28 PM, Marc Juul <juul(a)labitat.dk> wrote:
--
http://mitar.tnode.com/
https://twitter.com/mitar_m
On Thu, Apr 27, 2017 at 1:22 PM, Mitar <mitar(a)tnode.com> wrote:
> Hi!
>
>> IMO, we should put everything on ipv6 randomly generated link-local
>> addresses to avoid the whole makenode centralized IP assignment
> business.
>
> And how would you route that over L3 network?
>
> It would work over L2 Batman network. But not over L3.
>
> Have you looked into AHCP:
>
> https://www.irif.fr/~jch/software/ahcp/
Ssssh! Why did you have to tell them about AHCP?
... *OBLIVIATE!*
--
marc/juul
9:16 p.m.
Oops, yea not link local, but random. How do client devices get ipv4
addresses now? Not dhcp, right?
On Thu, Apr 27, 2017 at 8:44 PM, Mitar <mitar(a)tnode.com> wrote:
Hi!
Ah, for nodes. Yes, nodes could have automatic IPv6 addresses (and not
even link-local, but global).
For clients is trickier.
But we could do some automatic IPv6 address subnets for nodes. :-)
Mitar
--
http://mitar.tnode.com/
https://twitter.com/mitar_m
Well, I'm not an expert on all the details,
but I imagine we'd generate
them randomly during makenode (or whenever). Then routes to addresses
would
be propagated by babel in the same way that ipv4
addresses are now. I'm
not
sure if the exit server would need an ipv6
address or if it would be good
to switch existing nodes over.
-Jehan
On Thu, Apr 27, 2017 at 7:50 PM, Mitar <mitar(a)tnode.com> wrote:
> Hi!
>
> I was asking for the "IPv6 randomly generated link-local
> addresses" idea. How would that route?
>
>
> Mitar
>
>>> And how would you route that over L3 network?
>>
>> Off the top of my head:
>>
>> - Packet headed somewhere on the internet with an ipv4 address comes
> from a
>> client device to the home node.
>> - Home node pops that packet into an ipv6 packet bearing the ipv6
address
>> of the exit server which is then routed
over the mesh network
>> - Exit server takes the ipv4 packet out and does NAT on it (switches
the
>> source address to public IP) and sends it
out to the internet.
>> - Response from internet comes back to exit server, the exit server
does
>> NAT again (switches the destination
address to private IP)
>> - Exit server puts the packet into an ipv6 packet with the ipv6 address
> of
>> the home node and sends it onto the mesh (it needs to have kept track
of
>> the ipv6 address)
>> - Home node receives the ipv6 packet, takes the ipv4 packet out and
sends
>> it to the client.
>>
>> I'm not an expert, so there might be some issues with this. Here's an
RFC
which might be similar:
https://tools.ietf.org/html/rfc7040
On Thu, Apr 27, 2017 at 1:28 PM, Marc Juul <juul(a)labitat.dk> wrote:
>
>
> On Thu, Apr 27, 2017 at 1:22 PM, Mitar <mitar(a)tnode.com> wrote:
>
>> Hi!
>>
>>> IMO, we should put everything on ipv6 randomly generated link-local
>>> addresses to avoid the whole makenode centralized IP assignment
>> business.
>>
>> And how would you route that over L3 network?
>>
>> It would work over L2 Batman network. But not over L3.
>>
>> Have you looked into AHCP:
>>
>> https://www.irif.fr/~jch/software/ahcp/
>
>
> Ssssh! Why did you have to tell them about AHCP?
>
> ... *OBLIVIATE!*
>
> --
> marc/juul
>
--
http://mitar.tnode.com/
https://twitter.com/mitar_m
2566
days inactive
2567
days old
13 comments
3 participants
participants (3)
-
Jehan Tremback -
Marc Juul -
Mitar