I also thought of that, but I cannot adapt a datacenter network only for one probe :) Regards. -----Message d'origine----- De : gsmachado@gmail.com [mailto:gsmachado@gmail.com] De la part de Guilherme Sperb Machado Envoyé : mercredi 26 février 2014 12:23 À : Guillaume Sachot Cc : ripe-atlas@ripe.net Objet : Re: [atlas] Network configuration / Multiple VLANs Hello all, I faced the same issue when I configured the probes here. I solved such thing changing the network a bit, and putting both IP addresses in the same VLAN... but this is not optimum. Therefore, I agree, an additional VLAN field in the network configuration it would be great. :-) Cheers! On Wed, Feb 26, 2014 at 12:15 PM, Guillaume Sachot <gsachot@oceanet-technology.com> wrote:

Hi,

I have just received my Atlas probe, and I have an issue for the IPv6 part.

Its definitive IPv4 public address does not share the same VLAN with the IPv6 subnet. Would it be possible to add an optional VLAN field in the network configuration?

Thank you,

Regards.

--

Guillaume SACHOT

Oceanet Technology

Administrateur système et réseau

Support : +332 28 07 14 88

-- ---------------------------------------------------- MSc. Guilherme Sperb Machado Researcher & PhD. student at UZH (Universität Zürich) http://www.csg.uzh.ch/staff/machado/ ----------------------------------------------------

On Wed, 26 Feb 2014 12:28:14 +0100 Guillaume Sachot <gsachot@oceanet-technology.com> wrote:

I also thought of that, but I cannot adapt a datacenter network only for one probe :)

You don't have a "guest" VLAN for "here any visitor can plug in their laptop, and have internet-only (no internal services whatsoever) IPv4+IPv6 access"? Just place the probe into that same VLAN, it can't be trusted as it communicates with an external server and unconditionally accepts firmware upgrades from it anyway. Also having IPv4 and IPv6 in separate VLANs seems like a sign that whoever did the v6 deployment had little idea of wtf they are even doing. I wonder if many people have such a wretched configuration that it would warrant adding the whole VLAN option to the interface. -- With respect, Roman

Hi, You don't need to waste IPv4, just enable IPv6 in vlan where you already have IPv4 running. This is common deployment way - dual stack. And you don't waste IPv4 in this case. Regards. /Alex Saroyan On 02/26/2014 05:54 PM, Guillaume Sachot wrote:

...

You don't have a "guest" VLAN for "here any visitor can plug in their laptop, and have internet-only (no internal services whatsoever) IPv4+IPv6 access"? The guest network is WiFi based.

...

Also having IPv4 and IPv6 in separate VLANs seems like a sign that whoever did the v6 deployment had little idea of wtf they are even doing. I wonder if many people have such a wretched configuration that it would warrant adding the whole VLAN option to the interface. That's a bit presumptuous. Maybe the IPv6 VLAN is dedicated to this kind of external probes, and that we don't want to waste IPv4 by creating a dedicated one for the IPv4 counterpart when it can be put on an existing public range.

-----Message d'origine----- De : Roman Mamedov [mailto:rm@romanrm.net] Envoyé : mercredi 26 février 2014 14:24 À : Guillaume Sachot Cc : ripe-atlas@ripe.net Objet : Re: [atlas] Network configuration / Multiple VLANs

On Wed, 26 Feb 2014 12:28:14 +0100 Guillaume Sachot <gsachot@oceanet-technology.com> wrote:

...

I also thought of that, but I cannot adapt a datacenter network only for one probe :) You don't have a "guest" VLAN for "here any visitor can plug in their laptop, and have internet-only (no internal services whatsoever) IPv4+IPv6 access"? Just place the probe into that same VLAN, it can't be trusted as it communicates with an external server and unconditionally accepts firmware upgrades from it anyway.

Also having IPv4 and IPv6 in separate VLANs seems like a sign that whoever did the v6 deployment had little idea of wtf they are even doing. I wonder if many people have such a wretched configuration that it would warrant adding the whole VLAN option to the interface.

-- With respect, Roman

FWIW, my probe is sitting on its own "RIPE-ATLAS" VLAN . . . I have a lot of respect for the RIPE team - but dropping a device from a 3rd party, that you *know for a fact* it will get requests for tests from who-knows-where . . . A bit of a bad idea. Trust, but verify applies here - segment the probe into its own segment. Maybe an IPv6-only one . . . On 2/26/14 9:43 AM, "Guillaume Sachot" <gsachot@oceanet-technology.com> wrote:

Hi,

That's was not much a debate on doing dual stack on the same VLAN (we already do that), but to be able to put the IPv6 interface on a dedicated subnet for this kind of purpose, when you won't do that in your IPv4 network.

I prefer to think where would be the right place for a thing in an IPv6 network rather than planning a network only on the IPv4 constraints. We can all do our IPv6 subnetting based on what we have done in IPv4, but that would mostly be a bad idea.

Regards.

-----Message d'origine----- De : ripe-atlas-bounces@ripe.net [mailto:ripe-atlas-bounces@ripe.net] De la part de Alex Saroyan Envoyé : mercredi 26 février 2014 15:05 À : ripe-atlas@ripe.net Objet : Re: [atlas] Network configuration / Multiple VLANs

Hi,

You don't need to waste IPv4, just enable IPv6 in vlan where you already have IPv4 running. This is common deployment way - dual stack. And you don't waste IPv4 in this case.

Regards. /Alex Saroyan

On 02/26/2014 05:54 PM, Guillaume Sachot wrote:

...

...

You don't have a "guest" VLAN for "here any visitor can plug in their laptop, and have internet-only (no internal services whatsoever) IPv4+IPv6 access"? The guest network is WiFi based.

...

Also having IPv4 and IPv6 in separate VLANs seems like a sign that whoever did the v6 deployment had little idea of wtf they are even doing. I wonder if many people have such a wretched configuration that it would warrant adding the whole VLAN option to the interface. That's a bit presumptuous. Maybe the IPv6 VLAN is dedicated to this kind of external probes, and that we don't want to waste IPv4 by creating a dedicated one for the IPv4 counterpart when it can be put on an existing public range.

-----Message d'origine----- De : Roman Mamedov [mailto:rm@romanrm.net] Envoyé : mercredi 26 février 2014 14:24 À : Guillaume Sachot Cc : ripe-atlas@ripe.net Objet : Re: [atlas] Network configuration / Multiple VLANs

On Wed, 26 Feb 2014 12:28:14 +0100 Guillaume Sachot <gsachot@oceanet-technology.com> wrote:

...

I also thought of that, but I cannot adapt a datacenter network only for one probe :) You don't have a "guest" VLAN for "here any visitor can plug in their laptop, and have internet-only (no internal services whatsoever) IPv4+IPv6 access"? Just place the probe into that same VLAN, it can't be trusted as it communicates with an external server and unconditionally accepts firmware upgrades from it anyway.

Also having IPv4 and IPv6 in separate VLANs seems like a sign that whoever did the v6 deployment had little idea of wtf they are even doing. I wonder if many people have such a wretched configuration that it would warrant adding the whole VLAN option to the interface.

-- With respect, Roman

Then it could be a /30 network, right ? Or even a /31, if both probe and L3 device support RFC-3021 . . . In any case - my suggestion was NOT to deploy the probe on a network segment where, if compromised, could compromise the rest of the network - specially if you're dropping it on a network management / infrastructure segment. On 2/26/14 10:57 AM, "Roman Mamedov" <rm@romanrm.net> wrote:

On Wed, 26 Feb 2014 10:53:39 -0500 Dario Ciccarone <dario.ciccarone@gmail.com> wrote:

...

FWIW, my probe is sitting on its own "RIPE-ATLAS" VLAN . . .

I have a lot of respect for the RIPE team - but dropping a device from a 3rd party, that you *know for a fact* it will get requests for tests from who-knows-where . . . A bit of a bad idea.

Trust, but verify applies here - segment the probe into its own segment. Maybe an IPv6-only one . . .

AFAIK the probe currently does not support being on an IPv6-only network. Besides, why voluntarily make it half as useful to the world as it can be. You got the probe, got IPv4, might as well let the probe measure on IPv4...

-- With respect, Roman

Well, THAT is my scenario here - NAT for IPv4, and global unicast for IPv6 But in case you don't want to do NAT/can't . . . On 2/26/14 11:32 AM, "Roman Mamedov" <rm@romanrm.net> wrote:

On Wed, 26 Feb 2014 11:20:22 -0500 Dario Ciccarone <dario.ciccarone@gmail.com> wrote:

...

Then it could be a /30 network, right ? Or even a /31, if both probe and L3 device support RFC-3021 . . .

It could, and perhaps should, be an RFC1918 /24, NATed upstream by your router into whatever publicly routable IPs your site happens to have. Of course no one suggests or requires to waste any "real" IPv4 addresses just on the probe.

-- With respect, Roman