11 Mar
2017
11 Mar
'17
12:27 a.m.
Most of the discussion regarding this issue has been done on this pull
request:
https://github.com/libremesh/lime-packages/pull/71
I copy the last Daniel's statement from the lime-dev thread with subject
"[lime-dev] downloads.libremesh.org being unavailable" to keep
discussion from this point.
Do we have a consensus with regarding minPrefixLen,
maxPrefixLen and
using whether watchping should add/remove a route to 2000::/3 or ::/0?
To me it looked like we concluded to make the naming consistent with
the rest of lime ('publicv6') and use 2000::/3.
Yes, if there are not voices against it my vote is to use 2000::/3
instead of ::/0 for the Internet announcement.
But as commented on the pull-request limr-proto-bmx6 and lime-proto-bmx7
must be modified according this change ([1]).
Also this must be implemented to avoid problems with RFC6877:
so we should probably have several watchping sections
testing for
them. Ie. pinging a well-known IPv6-mapped IPv4 address and setting up
explicit tunIn for them.
But the prefix length
was still an ongoing debate and I'm also less flexible there, simply
because I cannot test things with maxPrefixLen >= 64 because all
ARPAnet gateways I have access to only got a single /64 and hence
should not delegate anything shorter than a /72 (ie. max 255 clouds
using that gateway). Thus it's impossible for me to actually test any
setup which involves shorter prefixes.
In any case we need a DHCPv6 server which allows the delegation of
prefixes smaller than /64. Current dnsmasq does not but we might patch
it. Using odhcpd means that we have to implement also the
dnsmasq-share-leases stuff into it. @Gui is our dnsmasq guy, let's see
what we says.
Also note that the counterpart, the needed changes on
the client-side
to make bmx6/7 automatically choose the right prefix and address is
still missing afaik and I don't have time to implement that right now.
We might try to involve @axn to this.
Anyway. Let me know what to do, I'll do it, so we
can move on :)
Great.
[1]
https://github.com/libremesh/lime-packages/blob/develop/packages/lime-proto…
--
./p4u
26 Mar
26 Mar
8:58 a.m.
On 11.03.2017 01:27, Pau wrote:
Most of the discussion regarding this issue has been
done on this pull
request:
https://github.com/libremesh/lime-packages/pull/71
I copy the last Daniel's statement from the lime-dev thread with subject
"[lime-dev] downloads.libremesh.org being unavailable" to keep
discussion from this point.
BTW: I am working on this. But it is not so trivial because if a GW
disappears or changes the prefix it offers to GW clients then all these
clients may have to reconfigure their tun-out interfaces because the
previously used source address of related tunnels has changed. Something
that yet only happens when the admin (or a script) of a GW-client node
changes the tun Addresses configuration. I dont have all the impacts and
required constrains of such automatic changes clear yet...
/axel
Do we have a consensus with regarding
minPrefixLen, maxPrefixLen and
using whether watchping should add/remove a route to 2000::/3 or ::/0?
To me it looked like we concluded to make the naming consistent with
the rest of lime ('publicv6') and use 2000::/3.
Yes, if there are not voices against it my vote is to use 2000::/3
instead of ::/0 for the Internet announcement.
But as commented on the pull-request limr-proto-bmx6 and lime-proto-bmx7
must be modified according this change ([1]).
Also this must be implemented to avoid problems with RFC6877:
so we should probably have several watchping
sections testing for
them. Ie. pinging a well-known IPv6-mapped IPv4 address and setting up
explicit tunIn for them.
But the prefix length
was still an ongoing debate and I'm also less flexible there, simply
because I cannot test things with maxPrefixLen >= 64 because all
ARPAnet gateways I have access to only got a single /64 and hence
should not delegate anything shorter than a /72 (ie. max 255 clouds
using that gateway). Thus it's impossible for me to actually test any
setup which involves shorter prefixes.
In any case we need a DHCPv6 server which allows the delegation of
prefixes smaller than /64. Current dnsmasq does not but we might patch
it. Using odhcpd means that we have to implement also the
dnsmasq-share-leases stuff into it. @Gui is our dnsmasq guy, let's see
what we says.
Also note that the counterpart, the needed
changes on the client-side
to make bmx6/7 automatically choose the right prefix and address is
still missing afaik and I don't have time to implement that right now.
We might try to involve @axn to this. Anyway. Let me know what to do, I'll do it,
so we can move on :)
Great.
[1]
https://github.com/libremesh/lime-packages/blob/develop/packages/lime-proto…
_______________________________________________
lime-dev mailing list
lime-dev(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-dev
3:47 p.m.
On 26/03/17 10:58, Axel Neumann wrote:
_______________________________________________
lime-dev mailing list
lime-dev(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-dev
--
./p4u
On 11.03.2017 01:27, Pau wrote:
Great to know that you are working on this. Keep us updated please.
Most of the discussion regarding this issue has
been done on this pull
request:
https://github.com/libremesh/lime-packages/pull/71
I copy the last Daniel's statement from the lime-dev thread with subject
"[lime-dev] downloads.libremesh.org being unavailable" to keep
discussion from this point.
BTW: I am working on this. But it is not so trivial because if a GW
disappears or changes the prefix it offers to GW clients then all these
clients may have to reconfigure their tun-out interfaces because the
previously used source address of related tunnels has changed. Something
that yet only happens when the admin (or a script) of a GW-client node
changes the tun Addresses configuration. I dont have all the impacts and
required constrains of such automatic changes clear yet...
/axel Do we have a consensus with regarding
minPrefixLen, maxPrefixLen and
using whether watchping should add/remove a route to 2000::/3 or ::/0?
To me it looked like we concluded to make the naming consistent with
the rest of lime ('publicv6') and use 2000::/3.
Yes, if there are not voices against it my vote is to use 2000::/3
instead of ::/0 for the Internet announcement.
But as commented on the pull-request limr-proto-bmx6 and lime-proto-bmx7
must be modified according this change ([1]).
Also this must be implemented to avoid problems with RFC6877:
so we should probably have several watchping
sections testing for
them. Ie. pinging a well-known IPv6-mapped IPv4 address and setting up
explicit tunIn for them.
But the prefix length
was still an ongoing debate and I'm also less flexible there, simply
because I cannot test things with maxPrefixLen >= 64 because all
ARPAnet gateways I have access to only got a single /64 and hence
should not delegate anything shorter than a /72 (ie. max 255 clouds
using that gateway). Thus it's impossible for me to actually test any
setup which involves shorter prefixes.
In any case we need a DHCPv6 server which allows the delegation of
prefixes smaller than /64. Current dnsmasq does not but we might patch
it. Using odhcpd means that we have to implement also the
dnsmasq-share-leases stuff into it. @Gui is our dnsmasq guy, let's see
what we says.
Also note that the counterpart, the needed
changes on the client-side
to make bmx6/7 automatically choose the right prefix and address is
still missing afaik and I don't have time to implement that right now.
We might try to involve @axn to this. Anyway. Let me know what to do, I'll do it,
so we can move on :)
Great.
[1]
https://github.com/libremesh/lime-packages/blob/develop/packages/lime-proto…
_______________________________________________
lime-dev mailing list
lime-dev(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-dev
5:17 p.m.
On Sun, Mar 26, 2017 at 05:47:38PM +0200, Pau wrote:
_______________________________________________
lime-dev mailing list
lime-dev(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-dev
--
./p4u
On 26/03/17 10:58, Axel Neumann wrote:
Great indeed! Let me know how I can support your efforts!
And just to clarify: Gateways changing their announced prefix are
something rather common, as in most cases (xDSL or DOCSIS consumer
grade ISP running DHCPv6) we'll have a temporarily assigned prefix with
a lease-time of only a couple of hours...
On 11.03.2017 01:27, Pau wrote:
Great to know that you are working on this. Keep us updated please. Most of the discussion regarding this issue has
been done on this pull
request:
https://github.com/libremesh/lime-packages/pull/71
I copy the last Daniel's statement from the lime-dev thread with subject
"[lime-dev] downloads.libremesh.org being unavailable" to keep
discussion from this point.
BTW: I am working on this. But it is not so trivial because if a GW
disappears or changes the prefix it offers to GW clients then all these
clients may have to reconfigure their tun-out interfaces because the
previously used source address of related tunnels has changed. Something
that yet only happens when the admin (or a script) of a GW-client node
changes the tun Addresses configuration. I dont have all the impacts and
required constrains of such automatic changes clear yet...
/axel Do we have a consensus with regarding
minPrefixLen, maxPrefixLen and
using whether watchping should add/remove a route to 2000::/3 or ::/0?
To me it looked like we concluded to make the naming consistent with
the rest of lime ('publicv6') and use 2000::/3.
Yes, if there are not voices against it my vote is to use 2000::/3
instead of ::/0 for the Internet announcement.
But as commented on the pull-request limr-proto-bmx6 and lime-proto-bmx7
must be modified according this change ([1]).
Also this must be implemented to avoid problems with RFC6877:
so we should probably have several watchping
sections testing for
them. Ie. pinging a well-known IPv6-mapped IPv4 address and setting up
explicit tunIn for them.
But the prefix length
was still an ongoing debate and I'm also less flexible there, simply
because I cannot test things with maxPrefixLen >= 64 because all
ARPAnet gateways I have access to only got a single /64 and hence
should not delegate anything shorter than a /72 (ie. max 255 clouds
using that gateway). Thus it's impossible for me to actually test any
setup which involves shorter prefixes.
In any case we need a DHCPv6 server which allows the delegation of
prefixes smaller than /64. Current dnsmasq does not but we might patch
it. Using odhcpd means that we have to implement also the
dnsmasq-share-leases stuff into it. @Gui is our dnsmasq guy, let's see
what we says.
Also note that the counterpart, the needed
changes on the client-side
to make bmx6/7 automatically choose the right prefix and address is
still missing afaik and I don't have time to implement that right now.
We might try to involve @axn to this. Anyway. Let me know what to do, I'll do it,
so we can move on :)
Great.
[1]
https://github.com/libremesh/lime-packages/blob/develop/packages/lime-proto…
_______________________________________________
lime-dev mailing list
lime-dev(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-dev
_______________________________________________
lime-dev mailing list
lime-dev(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-dev
2827
days inactive
2842
days old
3 comments
3 participants
participants (3)
-
Axel Neumann -
Daniel Golle -
Pau