Hi all,
I was just discussing IPv6 with Philip Colmer, our new IT Services Manager (cc'd on this mail), and it strikes me that we should at least be considering dual running at some point in the future, i.e. providing both v4 and v6. I'm not clear what the ramifications are, or as yet whether Zen will support it. Philip has experience with this, and seems to remember that Zen do support it, but I'll bang an e-mail out to them to check.
The reason for this e-mail is to start a discussion as to whether we think it's worth raising a BP, or if we can ignore this issue.
Thoughts, comments and brickbats welcome.
Thanks
Dave
Hi
from LEG perspective this is a good point to discuss for Hadoop. At the moment Apache Hadoop seems to have a limitation to work only with IPv4:http://wiki.apache.org/hadoop/HadoopIPv6 http://wiki.apache.org/hadoop/HadoopIPv6 leading to "no route to host" errors.
I do not think Cloudera is any better though I could not confirm this with an 'official' link.
So as LEG is looking towards exercising hadoop this means we will need IPv4 support. We should define what happens when BOTH ipv4/6 are supported. What we can check in LEG is which version of Hadoop to use and which limitations it has regarding ipv6.
BR, Ilias
On 12/10/2012 10:46 AM, Dave Pigott wrote:
Hi all,
I was just discussing IPv6 with Philip Colmer, our new IT Services Manager (cc'd on this mail), and it strikes me that we should at least be considering dual running at some point in the future, i.e. providing both v4 and v6. I'm not clear what the ramifications are, or as yet whether Zen will support it. Philip has experience with this, and seems to remember that Zen do support it, but I'll bang an e-mail out to them to check.
The reason for this e-mail is to start a discussion as to whether we think it's worth raising a BP, or if we can ignore this issue.
Thoughts, comments and brickbats welcome.
Thanks
Dave _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On Mon, Dec 10, 2012 at 9:46 AM, Dave Pigott dave.pigott@linaro.org wrote:
Hi all,
I was just discussing IPv6 with Philip Colmer, our new IT Services Manager (cc'd on this mail), and it strikes me that we should at least be considering dual running at some point in the future, i.e. providing both v4 and v6. I'm not clear what the ramifications are, or as yet whether Zen will support it. Philip has experience with this, and seems to remember that Zen do support it, but I'll bang an e-mail out to them to check.
The reason for this e-mail is to start a discussion as to whether we think it's worth raising a BP, or if we can ignore this issue.
Thoughts, comments and brickbats welcome.
I am quite sure that supporting IPv6 inside the LAVA lab is a worthwhile thing to do...
Whether we need public IPv6 or not, I don't have any strong feelings. I see that IPv6 is probably modern; so if it comes more or less for free I would say: let's think through this, make a plan and decide.
Thanks
Dave _______________________________________________ linaro-validation mailing list linaro-validation@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-validation
Alexander Sack asac@linaro.org writes:
On Mon, Dec 10, 2012 at 9:46 AM, Dave Pigott dave.pigott@linaro.org wrote:
Hi all,
I was just discussing IPv6 with Philip Colmer, our new IT Services Manager (cc'd on this mail), and it strikes me that we should at least be considering dual running at some point in the future, i.e. providing both v4 and v6. I'm not clear what the ramifications are, or as yet whether Zen will support it. Philip has experience with this, and seems to remember that Zen do support it, but I'll bang an e-mail out to them to check.
The reason for this e-mail is to start a discussion as to whether we think it's worth raising a BP, or if we can ignore this issue.
Thoughts, comments and brickbats welcome.
I am quite sure that supporting IPv6 inside the LAVA lab is a worthwhile thing to do...
What does this mean? FWIW, the ethernet interfaces on machines in the lab appear to have IPv6 addresses:
eth0 Link encap:Ethernet HWaddr 68:b5:99:be:54:8c inet addr:192.168.1.10 Bcast:255.255.0.0 Mask:255.255.0.0 inet6 addr: fe80::6ab5:99ff:febe:548c/64 Scope:Link <------------- HERE UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:20176938 errors:0 dropped:0 overruns:0 frame:0 TX packets:37330059 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:11878897411 (11.8 GB) TX bytes:50409227661 (50.4 GB) Interrupt:31 Memory:f8000000-f8012800
but I don't know if that means very much (I can't even get ping6 to talk to the address of eth0 on the host I'm running it on -- but I know very little about IPv6 in general).
One thing that maaaaybe we'll have to watch for is that until we have an IPv6 internet address we don't end up preferring AAAA records over A records when trying to connect to hosts that have both.
Whether we need public IPv6 or not, I don't have any strong feelings. I see that IPv6 is probably modern; so if it comes more or less for free I would say: let's think through this, make a plan and decide.
It seems Zen don't really support this yet. We can do 6in4/6to4 or whatever it's called if we want -- I guess the advantage of this would be being able to route to devices in the lab without having to bounce through linaro-gateway[0] but I don't know if that would be useful really[1].
[0] This is also a risk if we don't configure things correctly! We currently assume that various admin interfaces with weak passwords are not directly routeable. I presume that configuring this sort of thing is part of setting up 6in4 though.
[1] The person doing the routing would need to have access to the IPv6 internet too presumably, which I certainly don't have currently.
Cheers, mwh
OK,
In general it feels like this is a bit lower priority than many other topics ...
I propose: let's create a "LAVA lab IPv6 support" roadmap card where we collect the elements of IPv6 support.
Milestone forecast for delivery would be April or May 2013 for now I guess. Anyone volunteers to create the roadmap card stub?
On Tue, Dec 11, 2012 at 4:09 AM, Michael Hudson-Doyle michael.hudson@linaro.org wrote:
Alexander Sack asac@linaro.org writes:
On Mon, Dec 10, 2012 at 9:46 AM, Dave Pigott dave.pigott@linaro.org wrote:
Hi all,
I was just discussing IPv6 with Philip Colmer, our new IT Services Manager (cc'd on this mail), and it strikes me that we should at least be considering dual running at some point in the future, i.e. providing both v4 and v6. I'm not clear what the ramifications are, or as yet whether Zen will support it. Philip has experience with this, and seems to remember that Zen do support it, but I'll bang an e-mail out to them to check.
The reason for this e-mail is to start a discussion as to whether we think it's worth raising a BP, or if we can ignore this issue.
Thoughts, comments and brickbats welcome.
I am quite sure that supporting IPv6 inside the LAVA lab is a worthwhile thing to do...
What does this mean? FWIW, the ethernet interfaces on machines in the lab appear to have IPv6 addresses:
eth0 Link encap:Ethernet HWaddr 68:b5:99:be:54:8c inet addr:192.168.1.10 Bcast:255.255.0.0 Mask:255.255.0.0 inet6 addr: fe80::6ab5:99ff:febe:548c/64 Scope:Link <------------- HERE UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:20176938 errors:0 dropped:0 overruns:0 frame:0 TX packets:37330059 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:11878897411 (11.8 GB) TX bytes:50409227661 (50.4 GB) Interrupt:31 Memory:f8000000-f8012800
but I don't know if that means very much (I can't even get ping6 to talk to the address of eth0 on the host I'm running it on -- but I know very little about IPv6 in general).
One thing that maaaaybe we'll have to watch for is that until we have an IPv6 internet address we don't end up preferring AAAA records over A records when trying to connect to hosts that have both.
Whether we need public IPv6 or not, I don't have any strong feelings. I see that IPv6 is probably modern; so if it comes more or less for free I would say: let's think through this, make a plan and decide.
It seems Zen don't really support this yet. We can do 6in4/6to4 or whatever it's called if we want -- I guess the advantage of this would be being able to route to devices in the lab without having to bounce through linaro-gateway[0] but I don't know if that would be useful really[1].
[0] This is also a risk if we don't configure things correctly! We currently assume that various admin interfaces with weak passwords are not directly routeable. I presume that configuring this sort of thing is part of setting up 6in4 though.
[1] The person doing the routing would need to have access to the IPv6 internet too presumably, which I certainly don't have currently.
Cheers, mwh
FYI: I heard from Zen yesterday that public IPv6 support isn't on their roadmap as yet, so anything we do would purely have to be about internal testing of IPv6 support.
Thanks
Dave
On 11 Dec 2012, at 14:51, Alexander Sack asac@linaro.org wrote:
OK,
In general it feels like this is a bit lower priority than many other topics ...
I propose: let's create a "LAVA lab IPv6 support" roadmap card where we collect the elements of IPv6 support.
Milestone forecast for delivery would be April or May 2013 for now I guess. Anyone volunteers to create the roadmap card stub?
On Tue, Dec 11, 2012 at 4:09 AM, Michael Hudson-Doyle michael.hudson@linaro.org wrote:
Alexander Sack asac@linaro.org writes:
On Mon, Dec 10, 2012 at 9:46 AM, Dave Pigott dave.pigott@linaro.org wrote:
Hi all,
I was just discussing IPv6 with Philip Colmer, our new IT Services Manager (cc'd on this mail), and it strikes me that we should at least be considering dual running at some point in the future, i.e. providing both v4 and v6. I'm not clear what the ramifications are, or as yet whether Zen will support it. Philip has experience with this, and seems to remember that Zen do support it, but I'll bang an e-mail out to them to check.
The reason for this e-mail is to start a discussion as to whether we think it's worth raising a BP, or if we can ignore this issue.
Thoughts, comments and brickbats welcome.
I am quite sure that supporting IPv6 inside the LAVA lab is a worthwhile thing to do...
What does this mean? FWIW, the ethernet interfaces on machines in the lab appear to have IPv6 addresses:
eth0 Link encap:Ethernet HWaddr 68:b5:99:be:54:8c inet addr:192.168.1.10 Bcast:255.255.0.0 Mask:255.255.0.0 inet6 addr: fe80::6ab5:99ff:febe:548c/64 Scope:Link <------------- HERE UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:20176938 errors:0 dropped:0 overruns:0 frame:0 TX packets:37330059 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:11878897411 (11.8 GB) TX bytes:50409227661 (50.4 GB) Interrupt:31 Memory:f8000000-f8012800
but I don't know if that means very much (I can't even get ping6 to talk to the address of eth0 on the host I'm running it on -- but I know very little about IPv6 in general).
One thing that maaaaybe we'll have to watch for is that until we have an IPv6 internet address we don't end up preferring AAAA records over A records when trying to connect to hosts that have both.
Whether we need public IPv6 or not, I don't have any strong feelings. I see that IPv6 is probably modern; so if it comes more or less for free I would say: let's think through this, make a plan and decide.
It seems Zen don't really support this yet. We can do 6in4/6to4 or whatever it's called if we want -- I guess the advantage of this would be being able to route to devices in the lab without having to bounce through linaro-gateway[0] but I don't know if that would be useful really[1].
[0] This is also a risk if we don't configure things correctly! We currently assume that various admin interfaces with weak passwords are not directly routeable. I presume that configuring this sort of thing is part of setting up 6in4 though.
[1] The person doing the routing would need to have access to the IPv6 internet too presumably, which I certainly don't have currently.
Cheers, mwh
-- Alexander Sack Director, Linaro Platform Engineering http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#%21/linaroorg - http://www.linaro.org/linaro-blog
linaro-validation@lists.linaro.org
-
Alexander Sack -
Dave Pigott -
Ilias Biris -
Michael Hudson-Doyle