IPv6 only as default for next meeting
During WG this afternoon, the idea was submitted that the IPv6 only experimentation be made the default SSID for the next meeting. While this has been working tremendously well for routine internet usage, I've been unable to use this network mainly because of incompatibility with my VPN network. We have a dual-stack VPN. some of the resources are v4 only though. The DNS64 converts my v4 VPN resources into v6 resources that are then routed to the non-VPN interface. While there could be workarounds (DNS64 on the VPN side, full v6 routing on the VPN, or all VPN resources available on v6) I don't think the technology is mature enough to make it the default for advanced usage. My 0.02$
On 14 May 2015, at 18:21, Jérôme Fleury wrote:
During WG this afternoon, the idea was submitted that the IPv6 only experimentation be made the default SSID for the next meeting.
While this has been working tremendously well for routine internet usage, I've been unable to use this network mainly because of incompatibility with my VPN network.
We have a dual-stack VPN. some of the resources are v4 only though. The DNS64 converts my v4 VPN resources into v6 resources that are then routed to the non-VPN interface. While there could be workarounds (DNS64 on the VPN side, full v6 routing on the VPN, or all VPN resources available on v6) I don't think the technology is mature enough
I think the technology (v6only-nat64-dns64) is mature enough. The problem is that various applications and services are not compatible with it (usually IPv4 addresses negotiated in the payload) I know it is a variation, but what I’m trying to say is that if we can push more and more to have applications/services ipv6-ready, then that issue will just disappear. Marc.
to make it the default for advanced usage.
My 0.02$
Hi folks, this is admittedly a pet peeve of mine, so apologies right in advance to anybody getting offended by this, but I'd like to rephrase "Marc Blanchet" <marc.blanchet@viagenie.ca> writes:
I think the technology (v6only-nat64-dns64) is mature enough. The problem is that various applications and services are not compatible with it (usually IPv4 addresses negotiated in the payload)
as this: I think the technology (v6only-nat64-dns64) is inherently broken by design. By design it doesn't support a range of important and widely used existing applications and services that it should be compatible with to be considered "working". With NAT, NAT64 or whatever other application unaware translation hack being around, a lot of extra complexity is pushed towards the application layer. NAT* doesn't solve any problems, it just puts the burden on others who is unlikely in a situation to defend themselves (the app. developers) ; the overall effect is counterproductive. Aside from that, once we talk not full-blown computers but embedded devices, adding support for NAT penetration (STUN or whatever) is a major problem. The original Arduino uses a microcontroller with 32KB of flash (for program code) and 2KB of RAM, and that's already a fairly big one. Adding STUN support there is a serious problem. Again, this isn't meant as a flame or anything, but to show that these technologies have serious implications for others. Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
Hi Benedikt But in combination with 464XLAT it seems to do the job well enough to support millions of IPv6-only users for T-Mobile. And thereby allows them to deploy v6-only at the edge, where address consumption is highest. So maybe it would be good to differentiate a bit more and not throw out the baby with the bathwater. Silvia -----Ursprüngliche Nachricht----- Von: ipv6-wg [mailto:ipv6-wg-bounces@ripe.net] Im Auftrag von Benedikt Stockebrand Gesendet: Freitag, 15. Mai 2015 11:25 An: ipv6-wg@ripe.net IPv6 Betreff: [ipv6-wg] Implications of NAT/NAT64 and similar (was: Re: IPv6 only as default for next meeting) Hi folks, this is admittedly a pet peeve of mine, so apologies right in advance to anybody getting offended by this, but I'd like to rephrase "Marc Blanchet" <marc.blanchet@viagenie.ca> writes:
I think the technology (v6only-nat64-dns64) is mature enough. The problem is that various applications and services are not compatible with it (usually IPv4 addresses negotiated in the payload)
as this: I think the technology (v6only-nat64-dns64) is inherently broken by design. By design it doesn't support a range of important and widely used existing applications and services that it should be compatible with to be considered "working". With NAT, NAT64 or whatever other application unaware translation hack being around, a lot of extra complexity is pushed towards the application layer. NAT* doesn't solve any problems, it just puts the burden on others who is unlikely in a situation to defend themselves (the app. developers) ; the overall effect is counterproductive. Aside from that, once we talk not full-blown computers but embedded devices, adding support for NAT penetration (STUN or whatever) is a major problem. The original Arduino uses a microcontroller with 32KB of flash (for program code) and 2KB of RAM, and that's already a fairly big one. Adding STUN support there is a serious problem. Again, this isn't meant as a flame or anything, but to show that these technologies have serious implications for others. Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
Hi Silvia and list, Silvia Hagen <silvia.hagen@sunny.ch> writes:
Hi Benedikt
But in combination with 464XLAT it seems to do the job well enough to support millions of IPv6-only users for T-Mobile. And thereby allows them to deploy v6-only at the edge, where address consumption is highest.
So maybe it would be good to differentiate a bit more and not throw out the baby with the bathwater.
fair enough, but even then 464XLAT is a transition technology which following your reasoning causes a long term problem that software developers can't rely on end-to-end connectivity even with IPv6. In other words, while it helps in the short term, we'll pay dearly for it in the long run. Yes, of course you are right that this is a complex issue, but there's a widespread tendency to carry the old limitations of today's IPv4 to IPv6 even if there's no real need to do so. And Marc calling NAT64 a working solution despite the fact that it breaks IPv6 the same way NAT broke IPv4 really asks to be balanced by a similarly oversimplified statement going the other way:-) So the real question is: How do we deal with exactly that risk, i.e. that some transition technologies burden the IPv6 world with otherwise unnecessary legacy issues? Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
Hi, On Sun, May 17, 2015 at 04:49:29PM +0000, Benedikt Stockebrand wrote:
Yes, of course you are right that this is a complex issue, but there's a widespread tendency to carry the old limitations of today's IPv4 to IPv6 even if there's no real need to do so. And Marc calling NAT64 a working solution despite the fact that it breaks IPv6 the same way NAT broke IPv4 really asks to be balanced by a similarly oversimplified statement going the other way:-)
Actually, the whole point is that NAT64 does not touch IPv6, so it is not "breaking IPv6" - it ensures that IPv4 legacy is still reachable, even if you're inside an IPv6-only network. Which sounds quite positive to me, given the alternative is "run dual-stack everywhere, forever, because someone out there might still be IPv4-only"... Carriers can't "just turn off IPv4" if users still connect to IPv4-only sites... so what is worse, NAT44/CGN and dual-stack all the way to the client, or nice and shiny IPv6-only at the edges, and NAT64 for talking to the old Internet? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
YES :-) -----Ursprüngliche Nachricht----- Von: ipv6-wg [mailto:ipv6-wg-bounces@ripe.net] Im Auftrag von Gert Doering Gesendet: Sonntag, 17. Mai 2015 19:28 An: Benedikt Stockebrand Cc: ipv6-wg@ripe.net IPv6 Betreff: Re: [ipv6-wg] Implications of NAT/NAT64 and similar Hi, On Sun, May 17, 2015 at 04:49:29PM +0000, Benedikt Stockebrand wrote:
Yes, of course you are right that this is a complex issue, but there's a widespread tendency to carry the old limitations of today's IPv4 to IPv6 even if there's no real need to do so. And Marc calling NAT64 a working solution despite the fact that it breaks IPv6 the same way NAT broke IPv4 really asks to be balanced by a similarly oversimplified statement going the other way:-)
Actually, the whole point is that NAT64 does not touch IPv6, so it is not "breaking IPv6" - it ensures that IPv4 legacy is still reachable, even if you're inside an IPv6-only network. Which sounds quite positive to me, given the alternative is "run dual-stack everywhere, forever, because someone out there might still be IPv4-only"... Carriers can't "just turn off IPv4" if users still connect to IPv4-only sites... so what is worse, NAT44/CGN and dual-stack all the way to the client, or nice and shiny IPv6-only at the edges, and NAT64 for talking to the old Internet? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
On 18 May 2015, at 1:27, Gert Doering wrote:
Hi,
On Sun, May 17, 2015 at 04:49:29PM +0000, Benedikt Stockebrand wrote:
Yes, of course you are right that this is a complex issue, but there's a widespread tendency to carry the old limitations of today's IPv4 to IPv6 even if there's no real need to do so. And Marc calling NAT64 a working solution despite the fact that it breaks IPv6 the same way NAT broke IPv4 really asks to be balanced by a similarly oversimplified statement going the other way:-)
Actually, the whole point is that NAT64 does not touch IPv6, so it is not "breaking IPv6" - it ensures that IPv4 legacy is still reachable, even if you're inside an IPv6-only network.
Which sounds quite positive to me, given the alternative is "run dual-stack everywhere, forever, because someone out there might still be IPv4-only"...
Right. NAT64-DNS64, while not perfect, is to me the only viable solution to move from where we are now to IPv6 in a cost effective manner. Running dual-stack is not cost-effective, while ipv6-only could be. When we first talked about NAT64 a while ago, I hated it. But I became fast convinced that it is a very important tool to move to IPv6. Marc.
Carriers can't "just turn off IPv4" if users still connect to IPv4-only sites... so what is worse, NAT44/CGN and dual-stack all the way to the client, or nice and shiny IPv6-only at the edges, and NAT64 for talking to the old Internet?
Gert Doering -- NetMaster -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
On 17/May/15 19:46, Marc Blanchet wrote:
Right. NAT64-DNS64, while not perfect, is to me the only viable solution to move from where we are now to IPv6 in a cost effective manner. Running dual-stack is not cost-effective, while ipv6-only could be.
When we first talked about NAT64 a while ago, I hated it. But I became fast convinced that it is a very important tool to move to IPv6.
IMHO, NAT64/DNS64 is the only real solution out there - one that does not require an entire re-design of the network once the last IPv4 bit has been carried. Mark.
Transition mechanisms have the attribute of being transitional by definition. So they bridge gaps. That is exactly what NAT was originally designed for - bridge a gap until real solution is at hand. We have waited far too long with deploying IPv6, and now we have to live with the fact that IPv4 ran out. We are all paying the price and many have been predicting just that - but there weren't many that listened So let's hope we learned from the NAT issue We live in a free world and the Internet is VERY diverse. What is good for the ones is bad for others. If T-Mobile feels XLAT and NAT64 solves an issue, they and their customers must live with it. They can have an IPv6-only backbone and they can assign IPv6-only at the edge. Not bad. Maybe that helps the market to migrate the IPv4-legacy apps and design apps optimized for IPv6? :-) I do not believe in IETF or whoever else dictating the market how to do it. I think we should offer different transitional solutions solving different issues and let the actors in the market decide, what combination works best for them. My two cents Silvia -----Ursprüngliche Nachricht----- Von: ipv6-wg [mailto:ipv6-wg-bounces@ripe.net] Im Auftrag von Benedikt Stockebrand Gesendet: Sonntag, 17. Mai 2015 18:49 An: ipv6-wg@ripe.net IPv6 Betreff: Re: [ipv6-wg] Implications of NAT/NAT64 and similar Hi Silvia and list, Silvia Hagen <silvia.hagen@sunny.ch> writes:
Hi Benedikt
But in combination with 464XLAT it seems to do the job well enough to support millions of IPv6-only users for T-Mobile. And thereby allows them to deploy v6-only at the edge, where address consumption is highest.
So maybe it would be good to differentiate a bit more and not throw out the baby with the bathwater.
fair enough, but even then 464XLAT is a transition technology which following your reasoning causes a long term problem that software developers can't rely on end-to-end connectivity even with IPv6. In other words, while it helps in the short term, we'll pay dearly for it in the long run. Yes, of course you are right that this is a complex issue, but there's a widespread tendency to carry the old limitations of today's IPv4 to IPv6 even if there's no real need to do so. And Marc calling NAT64 a working solution despite the fact that it breaks IPv6 the same way NAT broke IPv4 really asks to be balanced by a similarly oversimplified statement going the other way:-) So the real question is: How do we deal with exactly that risk, i.e. that some transition technologies burden the IPv6 world with otherwise unnecessary legacy issues? Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
Hi Silvia and list, Silvia Hagen <silvia.hagen@sunny.ch> writes:
Transition mechanisms have the attribute of being transitional by definition. So they bridge gaps. That is exactly what NAT was originally designed for - bridge a gap until real solution is at hand. [...]
yes, but they also have another effect: They make people believe that the problem is solved, often leading to a situation where these stopgap measures don't work any longer and the pressure to fix the problem is *really* bad. Or, in a different context: As long as the painkillers work, why should I go to the dentist? Only when the workaround is more painful than the problem it solves, then people start to move. We see that with DS-Lite, which is why I called it so useful at the RIPE meeting in Amsterdam: To the ISPs and the content providers, and increasingly to the enterprises too, it is simply less painful to go server side dual-stack than deal with the collateral damage caused by IPv4-only on their side and DS-Lite on their users.
So let's hope we learned from the NAT issue
Seriously, I doubt that; this behaviour is too deeply entrenched in peoples minds. And while we're both making a living out of IPv6, it's still a niche market for people like us; if people had learned, then we'd be drowning in project offers.
We live in a free world and the Internet is VERY diverse. What is good for the ones is bad for others.
Fully agree on that. And it's rather difficult to come up with ideas or approaches that won't cause significant problems for others. But that's exactly why I point out the problems NAT causes to other people.
I do not believe in IETF or whoever else dictating the market how to do it.
Hmm, I guess there are a number of people at the IETF who'd be quite seriously offended by that statement, but anyway: One of the most fundamental goals of the Internet and the technologies used there is interoperability. I still remember how Compuserve and AOL and MSN and various others tried to establish their proprietary internetworking products, and people eventually opted for the Internet largely because of its interoperability. The role of the IETF is to ensure that specifications (not standards by the way, but that's yet another issue:-) support this interoperation.
I think we should offer different transitional solutions solving different issues and let the actors in the market decide, what combination works best for them.
Yes, but: If the "market decides" then there's a good chance that people will sacrifice that interoperability for their own advantage. There are some people who benefit from full-blown NAT66, but others will then have to pay the price (STUN, reduced reliability, increased operational expenses, extra hardware, ...). One of the problems with transitional solutions, aside from delaying the inevitable until it really hurts, and always lasting forever, is that each increases complexity. And considering how difficult it is to recall those solutions when once made available. Which leads back to the extension header issue... Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
On 15-May-2015 02:25 am, Benedikt Stockebrand <bs@stepladder-it.com> wrote:
Hi folks,
this is admittedly a pet peeve of mine, so apologies right in advance to anybody getting offended by this, but I'd like to rephrase
"Marc Blanchet" <marc.blanchet@viagenie.ca> writes:
I think the technology (v6only-nat64-dns64) is mature enough. The problem is that various applications and services are not compatible with it (usually IPv4 addresses negotiated in the payload)
as this:
I think the technology (v6only-nat64-dns64) is inherently broken by design. By design it doesn't support a range of important and widely used existing applications and services that it should be compatible with to be considered "working".
With NAT, NAT64 or whatever other application unaware translation hack being around, a lot of extra complexity is pushed towards the application layer. NAT* doesn't solve any problems, it just puts the burden on others who is unlikely in a situation to defend themselves (the app. developers) ; the overall effect is counterproductive.
Aside from that, once we talk not full-blown computers but embedded devices, adding support for NAT penetration (STUN or whatever) is a major problem. The original Arduino uses a microcontroller with 32KB of flash (for program code) and 2KB of RAM, and that's already a fairly big one. Adding STUN support there is a serious problem.
Again, this isn't meant as a flame or anything, but to show that these technologies have serious implications for others.
To avoid some of that, they can go IPv6-only, including their servers and all peers they communicate with, then there doesn't need to be NAT64 for their traffic. But even IPv6-only they will need firewall traversal support, as firewalls by default will block unsolicited incoming traffic (RFC6092). -d
Hi Dan and list, 🔓Dan Wing <dwing@cisco.com> writes:
On 15-May-2015 02:25 am, Benedikt Stockebrand <bs@stepladder-it.com> wrote:
[Implications of NAT64]
To avoid some of that, they can go IPv6-only, including their servers and all peers they communicate with, then there doesn't need to be NAT64 for their traffic. But even IPv6-only they will need firewall traversal support, as firewalls by default will block unsolicited incoming traffic (RFC6092).
I'm not sure if I get you correctly, but: Do you mean IPv6 only, or dual-stacked servers (so whatever a client connects with works without translation)? Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
On 17-May-2015 09:52 am, Benedikt Stockebrand <bs@stepladder-it.com> wrote:
Hi Dan and list,
🔓Dan Wing <dwing@cisco.com> writes:
On 15-May-2015 02:25 am, Benedikt Stockebrand <bs@stepladder-it.com> wrote:
[Implications of NAT64]
To avoid some of that, they can go IPv6-only, including their servers and all peers they communicate with, then there doesn't need to be NAT64 for their traffic. But even IPv6-only they will need firewall traversal support, as firewalls by default will block unsolicited incoming traffic (RFC6092).
I'm not sure if I get you correctly, but: Do you mean IPv6 only, or dual-stacked servers (so whatever a client connects with works without translation)?
Go IPv6-only. If servers run IPv4 there will be a NAT on path, necessitating the NAT traversal support in the client. But IPv6-only reduces the market to only those homes/businesses with IPv6. Short version of what I'm saying: there is no way to avoid NAT translation support in the client. -d
On Fri, May 15, 2015, at 00:21, Jérôme Fleury wrote:
During WG this afternoon, the idea was submitted that the IPv6 only experimentation be made the default SSID for the next meeting.
While this has been working tremendously well for routine internet usage, I've been unable to use this network mainly because of incompatibility with my VPN network.
Hi Jerome, The VPN clients (almost all of them) are actually changing your host from a IPv6-only one to a dual-stacked one. The "split DNS" feature is supposed to solve (or at least alleviate) the problem if available and enabled. A somehow similar situation (IPv6 only device turned dual-stack) arises when you use your mobile phone on the v6-only network, with mobile data still turned on.The problem in that set-up is that you are not able to see misbehaving applications, since they may be using the 3G/4G interface to communicate using IPv4. I've seen this happening with Lollipop (Kitekat was not working at all on v6-only network). Does somebody have any idea about the exact situation in Apple/iOS-land ?
On Fri, May 15, 2015 at 12:21 AM, Jérôme Fleury <jerome@fleury.net> wrote:
During WG this afternoon, the idea was submitted that the IPv6 only experimentation be made the default SSID for the next meeting.
While this has been working tremendously well for routine internet usage, I've been unable to use this network mainly because of incompatibility with my VPN network.
We have a dual-stack VPN. some of the resources are v4 only though. The DNS64 converts my v4 VPN resources into v6 resources that are then routed to the non-VPN interface. While there could be workarounds (DNS64 on the VPN side, full v6 routing on the VPN, or all VPN resources available on v6) I don't think the technology is mature enough to make it the default for advanced usage.
My 0.02$
We could set up some kind of (friendly) rate limiting for the v4 network to make all regular users _want_ to be on the v6 network, which would not be limited. I can confirm all the major stuff was working, but I am sure not everybody tried. For those who still need v4, the fallback network with v4 would work, and it would maybe make them submit a ticket with their software vendor for incompatible applications (not necessarily including your problem, which seems to be more of a design thing) - Volker D. Pallas
Hello list, Dne 17.5.2015 v 21:28 Volker D. Pallas napsal(a):
We could set up some kind of (friendly) rate limiting for the v4 network to make all regular users _want_ to be on the v6 network, which would not be limited. I can confirm all the major stuff was working, but I am sure not everybody tried.
My observation is that most people haven't tried the v6only network just because they had troubles learning its password. That especially affects the newcommers. I don't think it is reasonable to rate limit the legacy network, proper naming should be sufficient. I would adopt naming convention in the same way the NCC promotes 5 GHz Wi-Fi technology instead of 2,4 GHz: Network type || 5 GHz essid | 2,4 GHz essid ---------------++----------------+-------------------- IPv6 + NAT64 || ripemtg | ripemtg-2.4 IPv6 + IPv4 || ripemtg-legacy | ripemtg-legacy-2.4 This way everybody would probably try the v6only network first and only those that would fail would switchover to legacy network. It would be then really useful to see the nuber of clients for which the v6only network is sufficient. -- Ondřej Caletka CESNET
Ondřej, On Mon, 18 May 2015 13:58:05 +0200 Ondřej Caletka <Ondrej.Caletka@cesnet.cz> wrote:
Dne 17.5.2015 v 21:28 Volker D. Pallas napsal(a): My observation is that most people haven't tried the v6only network just because they had troubles learning its password. That especially affects the newcommers.
I think this is probably true.
I don't think it is reasonable to rate limit the legacy network, proper naming should be sufficient. I would adopt naming convention in the same way the NCC promotes 5 GHz Wi-Fi technology instead of 2,4 GHz:
Network type || 5 GHz essid | 2,4 GHz essid ---------------++----------------+-------------------- IPv6 + NAT64 || ripemtg | ripemtg-2.4 IPv6 + IPv4 || ripemtg-legacy | ripemtg-legacy-2.4
This way everybody would probably try the v6only network first and only those that would fail would switchover to legacy network. It would be then really useful to see the nuber of clients for which the v6only network is sufficient.
If we wanted to be very cautious, we could try just changing the password for RIPE 71 to be the same, and then in RIPE 72 changing the default to be what you've put in the chart here. I'm happy with your proposal for RIPE 71, of course, since I don't have horrible VPN software from the 20th century. ;) Cheers, -- Shane
Hi, On Mon, May 18, 2015 at 12:39:41PM +0000, Shane Kerr wrote:
I'm happy with your proposal for RIPE 71, of course, since I don't have horrible VPN software from the 20th century. ;)
Thing is, this wasn't actually the VPN software's doing, but DNS(64) - so if you try to access an IPv4-host *inside* the VPN, but try to resolve it using the public recursive DNS that you've been given, your client will receive an IPv6 address instead... With "full redirect VPN" this works (redirect DNS inside the VPN) but with "split tunnel" VPN, you're basically stuck between a rock and a hard place here - either you use the inside DNS, then your access to outside IPv4-only places fails (no DNS64), or you use the outside DNS, then see above... Gert Doering -- part time VPN software maintainer -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
participants (11)
-
Benedikt Stockebrand -
Gert Doering -
Jérôme Fleury -
Marc Blanchet -
Mark Tinka -
Ondřej Caletka -
Radu-Adrian FEURDEAN -
Shane Kerr -
Silvia Hagen -
Volker D. Pallas -
🔓Dan Wing