IPv6 Only Network at RIPE 67
"It's an IPv6 Working Group Initiative!" Dear Colleagues, Following the discussion at RIPE 66, the IPv6 Working Group is happy to provide you with an experimental network that is configured to offer only IPv6. This experimental network is not supported by the RIPE NCC or RIPE 67 Technical Team. We encourage everybody to connect to this network and test any websites, applications, hardware and software, and verify that they operate when an IPv4 address is no longer available. Important: This network is an experiment and is offered on a best-effort basis. We will try to maintain sufficient service levels and are happy to look into and help troubleshoot any issues you may encounter. If you rely on network connectivity for important business, we recommend you connect to the regular RIPE Meeting network. How to connect: - Make sure IPv6 is enabled on your device - Connect to SSID: IPV6ONLYEXP - Enter the password: iknowbesteffort The network provides NAT64 translation to connect to legacy services – please use the name server provided by the network to make use of this feature. We suggest you leave IPv4 enabled as this will be the scenario for most end users. Feedback: Please see Marco Hogewoning or Andrew Yourtchenko for any issues. We invite you to attend the IPv6 Working Group session on Thursday from 9:00-10:30 to discuss the results of this experiment. And of course you are welcome to follow up on this mailing list. Greetings, Marco Hogewoning Andrew Yourtchenko
On Sun, Oct 13, 2013 at 12:04 PM, Marco Hogewoning <marcoh@marcoh.net> wrote: <snip>
We encourage everybody to connect to this network and test any websites, applications, hardware and software, and verify that they operate when an IPv4 address is no longer available.
Windows 7 had some initial issues, think the initial issue was more of a timing/timeout issue when I moved from a regular IPv4 SSID over to IPv6 only. Seemed like win7 expected IPv4 and when it got none it considered the SSID as failed and moved on. After a disconnect, poweroff/on wifi and then reconnect it connected just fine. Android on the other hand failed horrible with IPv6 only, (Android 4.0.*/4.2 and 4.3), it expect IPv4 and when it don't get it after a while it move on to the next SSID it can connect to. -- Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no
The easy answer is " that is why we run this test". Unfortunate to hear Android doesn't work, hopefully somebody is able to correct this based on reports like this. MarcoH -- Sent from mobile, sorry for the typos On 14 okt. 2013, at 10:41, Roger Jørgensen <rogerj@gmail.com> wrote:
On Sun, Oct 13, 2013 at 12:04 PM, Marco Hogewoning <marcoh@marcoh.net> wrote: <snip>
We encourage everybody to connect to this network and test any websites, applications, hardware and software, and verify that they operate when an IPv4 address is no longer available.
Windows 7 had some initial issues, think the initial issue was more of a timing/timeout issue when I moved from a regular IPv4 SSID over to IPv6 only. Seemed like win7 expected IPv4 and when it got none it considered the SSID as failed and moved on. After a disconnect, poweroff/on wifi and then reconnect it connected just fine.
Android on the other hand failed horrible with IPv6 only, (Android 4.0.*/4.2 and 4.3), it expect IPv4 and when it don't get it after a while it move on to the next SSID it can connect to.
--
Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no
It seems not better with Ios Lionel HOFFMANN DIRECTION TECHNIQUE Fixe: 01 39 45 42 76 Mobile: 06 60 31 42 76 Email: lhoffman@bouyguestelecom.fr Adresse: 13/15 Avenue du maréchal Juin 92360 MEUDON -----Message d'origine----- De : ipv6-wg-bounces@ripe.net [mailto:ipv6-wg-bounces@ripe.net] De la part de MarcoH Envoyé : lundi 14 octobre 2013 10:19 À : Roger Jørgensen Cc : ipv6-wg@ripe.net IPv6 Objet : Re: [ipv6-wg] IPv6 Only Network at RIPE 67 The easy answer is " that is why we run this test". Unfortunate to hear Android doesn't work, hopefully somebody is able to correct this based on reports like this. MarcoH -- Sent from mobile, sorry for the typos On 14 okt. 2013, at 10:41, Roger Jørgensen <rogerj@gmail.com> wrote:
On Sun, Oct 13, 2013 at 12:04 PM, Marco Hogewoning <marcoh@marcoh.net> wrote: <snip>
We encourage everybody to connect to this network and test any websites, applications, hardware and software, and verify that they operate when an IPv4 address is no longer available.
Windows 7 had some initial issues, think the initial issue was more of a timing/timeout issue when I moved from a regular IPv4 SSID over to IPv6 only. Seemed like win7 expected IPv4 and when it got none it considered the SSID as failed and moved on. After a disconnect, poweroff/on wifi and then reconnect it connected just fine.
Android on the other hand failed horrible with IPv6 only, (Android 4.0.*/4.2 and 4.3), it expect IPv4 and when it don't get it after a while it move on to the next SSID it can connect to.
--
Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no
________________________________ L'intégrité de ce message n'étant pas assurée sur internet, la société expéditrice ne peut être tenue responsable de son contenu ni de ses pièces jointes. Toute utilisation ou diffusion non autorisée est interdite. Si vous n'êtes pas destinataire de ce message, merci de le détruire et d'avertir l'expéditeur. The integrity of this message cannot be guaranteed on the Internet. The company that sent this message cannot therefore be held liable for its content nor attachments. Any unauthorized use or dissemination is prohibited. If you are not the intended recipient of this message, then please delete it and notify the sender.
Facebook Apps said "No Internet Connection" on iPhone4s with iOS7. -- TACHIBANA toshio On Mon, Oct 14, 2013 at 6:40 PM, HOFFMANN, Lionel <LHOFFMAN@bouyguestelecom.fr> wrote:
It seems not better with Ios
Lionel HOFFMANN DIRECTION TECHNIQUE Fixe: 01 39 45 42 76 Mobile: 06 60 31 42 76 Email: lhoffman@bouyguestelecom.fr Adresse: 13/15 Avenue du maréchal Juin 92360 MEUDON
-----Message d'origine----- De : ipv6-wg-bounces@ripe.net [mailto:ipv6-wg-bounces@ripe.net] De la part de MarcoH Envoyé : lundi 14 octobre 2013 10:19 À : Roger Jørgensen Cc : ipv6-wg@ripe.net IPv6 Objet : Re: [ipv6-wg] IPv6 Only Network at RIPE 67
The easy answer is " that is why we run this test". Unfortunate to hear Android doesn't work, hopefully somebody is able to correct this based on reports like this.
MarcoH -- Sent from mobile, sorry for the typos
On 14 okt. 2013, at 10:41, Roger Jørgensen <rogerj@gmail.com> wrote:
On Sun, Oct 13, 2013 at 12:04 PM, Marco Hogewoning <marcoh@marcoh.net> wrote: <snip>
We encourage everybody to connect to this network and test any websites, applications, hardware and software, and verify that they operate when an IPv4 address is no longer available.
Windows 7 had some initial issues, think the initial issue was more of a timing/timeout issue when I moved from a regular IPv4 SSID over to IPv6 only. Seemed like win7 expected IPv4 and when it got none it considered the SSID as failed and moved on. After a disconnect, poweroff/on wifi and then reconnect it connected just fine.
Android on the other hand failed horrible with IPv6 only, (Android 4.0.*/4.2 and 4.3), it expect IPv4 and when it don't get it after a while it move on to the next SSID it can connect to.
--
Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no
________________________________
L'intégrité de ce message n'étant pas assurée sur internet, la société expéditrice ne peut être tenue responsable de son contenu ni de ses pièces jointes. Toute utilisation ou diffusion non autorisée est interdite. Si vous n'êtes pas destinataire de ce message, merci de le détruire et d'avertir l'expéditeur.
The integrity of this message cannot be guaranteed on the Internet. The company that sent this message cannot therefore be held liable for its content nor attachments. Any unauthorized use or dissemination is prohibited. If you are not the intended recipient of this message, then please delete it and notify the sender.
I can not reach dns server 2001:67c:64:48::cafe as I'm receiving "Hop Limit Exceeded" from 2001:67c:64:49::1:1 On Mon, Oct 14, 2013 at 12:21 PM, TACHIBANA toshio <toshio@aniani.com> wrote:
Facebook Apps said "No Internet Connection" on iPhone4s with iOS7.
-- TACHIBANA toshio
On Mon, Oct 14, 2013 at 6:40 PM, HOFFMANN, Lionel <LHOFFMAN@bouyguestelecom.fr> wrote:
It seems not better with Ios
Lionel HOFFMANN DIRECTION TECHNIQUE Fixe: 01 39 45 42 76 Mobile: 06 60 31 42 76 Email: lhoffman@bouyguestelecom.fr Adresse: 13/15 Avenue du maréchal Juin 92360 MEUDON
-----Message d'origine----- De : ipv6-wg-bounces@ripe.net [mailto:ipv6-wg-bounces@ripe.net] De la part de MarcoH Envoyé : lundi 14 octobre 2013 10:19 À : Roger Jørgensen Cc : ipv6-wg@ripe.net IPv6 Objet : Re: [ipv6-wg] IPv6 Only Network at RIPE 67
The easy answer is " that is why we run this test". Unfortunate to hear Android doesn't work, hopefully somebody is able to correct this based on reports like this.
MarcoH -- Sent from mobile, sorry for the typos
On 14 okt. 2013, at 10:41, Roger Jørgensen <rogerj@gmail.com> wrote:
On Sun, Oct 13, 2013 at 12:04 PM, Marco Hogewoning <marcoh@marcoh.net> wrote: <snip>
We encourage everybody to connect to this network and test any websites, applications, hardware and software, and verify that they operate when an IPv4 address is no longer available.
Windows 7 had some initial issues, think the initial issue was more of a timing/timeout issue when I moved from a regular IPv4 SSID over to IPv6 only. Seemed like win7 expected IPv4 and when it got none it considered the SSID as failed and moved on. After a disconnect, poweroff/on wifi and then reconnect it connected just fine.
Android on the other hand failed horrible with IPv6 only, (Android 4.0.*/4.2 and 4.3), it expect IPv4 and when it don't get it after a while it move on to the next SSID it can connect to.
--
Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no
________________________________
L'intégrité de ce message n'étant pas assurée sur internet, la société expéditrice ne peut être tenue responsable de son contenu ni de ses pièces jointes. Toute utilisation ou diffusion non autorisée est interdite. Si vous n'êtes pas destinataire de ce message, merci de le détruire et d'avertir l'expéditeur.
The integrity of this message cannot be guaranteed on the Internet. The company that sent this message cannot therefore be held liable for its content nor attachments. Any unauthorized use or dissemination is prohibited. If you are not the intended recipient of this message, then please delete it and notify the sender.
-- SY, Jen Linkova aka Furry
Thanks, we'll look into it. Grtx, MarcoH -- "Life is like riding a bicycle. To keep your balance you must keep moving" -- Albert Einstein On Oct 14, 2013, at 2:04 PM, Jen Linkova <furry13@gmail.com> wrote:
I can not reach dns server 2001:67c:64:48::cafe as I'm receiving "Hop Limit Exceeded" from 2001:67c:64:49::1:1
On Mon, Oct 14, 2013 at 12:21 PM, TACHIBANA toshio <toshio@aniani.com> wrote:
Facebook Apps said "No Internet Connection" on iPhone4s with iOS7.
-- TACHIBANA toshio
On Mon, Oct 14, 2013 at 6:40 PM, HOFFMANN, Lionel <LHOFFMAN@bouyguestelecom.fr> wrote:
It seems not better with Ios
Lionel HOFFMANN DIRECTION TECHNIQUE Fixe: 01 39 45 42 76 Mobile: 06 60 31 42 76 Email: lhoffman@bouyguestelecom.fr Adresse: 13/15 Avenue du maréchal Juin 92360 MEUDON
-----Message d'origine----- De : ipv6-wg-bounces@ripe.net [mailto:ipv6-wg-bounces@ripe.net] De la part de MarcoH Envoyé : lundi 14 octobre 2013 10:19 À : Roger Jørgensen Cc : ipv6-wg@ripe.net IPv6 Objet : Re: [ipv6-wg] IPv6 Only Network at RIPE 67
The easy answer is " that is why we run this test". Unfortunate to hear Android doesn't work, hopefully somebody is able to correct this based on reports like this.
MarcoH -- Sent from mobile, sorry for the typos
On 14 okt. 2013, at 10:41, Roger Jørgensen <rogerj@gmail.com> wrote:
On Sun, Oct 13, 2013 at 12:04 PM, Marco Hogewoning <marcoh@marcoh.net> wrote: <snip>
We encourage everybody to connect to this network and test any websites, applications, hardware and software, and verify that they operate when an IPv4 address is no longer available.
Windows 7 had some initial issues, think the initial issue was more of a timing/timeout issue when I moved from a regular IPv4 SSID over to IPv6 only. Seemed like win7 expected IPv4 and when it got none it considered the SSID as failed and moved on. After a disconnect, poweroff/on wifi and then reconnect it connected just fine.
Android on the other hand failed horrible with IPv6 only, (Android 4.0.*/4.2 and 4.3), it expect IPv4 and when it don't get it after a while it move on to the next SSID it can connect to.
--
Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no
________________________________
L'intégrité de ce message n'étant pas assurée sur internet, la société expéditrice ne peut être tenue responsable de son contenu ni de ses pièces jointes. Toute utilisation ou diffusion non autorisée est interdite. Si vous n'êtes pas destinataire de ce message, merci de le détruire et d'avertir l'expéditeur.
The integrity of this message cannot be guaranteed on the Internet. The company that sent this message cannot therefore be held liable for its content nor attachments. Any unauthorized use or dissemination is prohibited. If you are not the intended recipient of this message, then please delete it and notify the sender.
-- SY, Jen Linkova aka Furry
Yes, we appear to have lost our server. We are on our way in trying to find out what happened and get it restarted. Sorry, MarcoH -- "Life is like riding a bicycle. To keep your balance you must keep moving" -- Albert Einstein On Oct 14, 2013, at 2:04 PM, Jen Linkova <furry13@gmail.com> wrote:
I can not reach dns server 2001:67c:64:48::cafe as I'm receiving "Hop Limit Exceeded" from 2001:67c:64:49::1:1
On Mon, Oct 14, 2013 at 12:21 PM, TACHIBANA toshio <toshio@aniani.com> wrote:
Facebook Apps said "No Internet Connection" on iPhone4s with iOS7.
-- TACHIBANA toshio
On Mon, Oct 14, 2013 at 6:40 PM, HOFFMANN, Lionel <LHOFFMAN@bouyguestelecom.fr> wrote:
It seems not better with Ios
Lionel HOFFMANN DIRECTION TECHNIQUE Fixe: 01 39 45 42 76 Mobile: 06 60 31 42 76 Email: lhoffman@bouyguestelecom.fr Adresse: 13/15 Avenue du maréchal Juin 92360 MEUDON
-----Message d'origine----- De : ipv6-wg-bounces@ripe.net [mailto:ipv6-wg-bounces@ripe.net] De la part de MarcoH Envoyé : lundi 14 octobre 2013 10:19 À : Roger Jørgensen Cc : ipv6-wg@ripe.net IPv6 Objet : Re: [ipv6-wg] IPv6 Only Network at RIPE 67
The easy answer is " that is why we run this test". Unfortunate to hear Android doesn't work, hopefully somebody is able to correct this based on reports like this.
MarcoH -- Sent from mobile, sorry for the typos
On 14 okt. 2013, at 10:41, Roger Jørgensen <rogerj@gmail.com> wrote:
On Sun, Oct 13, 2013 at 12:04 PM, Marco Hogewoning <marcoh@marcoh.net> wrote: <snip>
We encourage everybody to connect to this network and test any websites, applications, hardware and software, and verify that they operate when an IPv4 address is no longer available.
Windows 7 had some initial issues, think the initial issue was more of a timing/timeout issue when I moved from a regular IPv4 SSID over to IPv6 only. Seemed like win7 expected IPv4 and when it got none it considered the SSID as failed and moved on. After a disconnect, poweroff/on wifi and then reconnect it connected just fine.
Android on the other hand failed horrible with IPv6 only, (Android 4.0.*/4.2 and 4.3), it expect IPv4 and when it don't get it after a while it move on to the next SSID it can connect to.
--
Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no
________________________________
L'intégrité de ce message n'étant pas assurée sur internet, la société expéditrice ne peut être tenue responsable de son contenu ni de ses pièces jointes. Toute utilisation ou diffusion non autorisée est interdite. Si vous n'êtes pas destinataire de ce message, merci de le détruire et d'avertir l'expéditeur.
The integrity of this message cannot be guaranteed on the Internet. The company that sent this message cannot therefore be held liable for its content nor attachments. Any unauthorized use or dissemination is prohibited. If you are not the intended recipient of this message, then please delete it and notify the sender.
-- SY, Jen Linkova aka Furry
We should back online, come to the IPv6 Working Group on Thursday for I'm sure an interesting incident report. Marco
I've seen some people struggle with DNS settings. You need to use the resolver that sits in the ipv6-only network for NAT64 to work and in any case you need to have a resolver that is reachable over IPv6. If you have any manual config (such as google resolver) it probably doesn't work as your machine will try and insists on using those. We offer DNS resolvers using DHCPv6 and the RA option, older clients might not support either protocol. If you want to try manual configuration, the resolver sits on 2001:67c:64:48::cafe Grtx, MarcoH -- "Life is like riding a bicycle. To keep your balance you must keep moving" -- Albert Einstein On Oct 14, 2013, at 1:21 PM, TACHIBANA toshio <toshio@aniani.com> wrote:
Facebook Apps said "No Internet Connection" on iPhone4s with iOS7.
-- TACHIBANA toshio
On Mon, Oct 14, 2013 at 6:40 PM, HOFFMANN, Lionel <LHOFFMAN@bouyguestelecom.fr> wrote:
It seems not better with Ios
Lionel HOFFMANN DIRECTION TECHNIQUE Fixe: 01 39 45 42 76 Mobile: 06 60 31 42 76 Email: lhoffman@bouyguestelecom.fr Adresse: 13/15 Avenue du maréchal Juin 92360 MEUDON
-----Message d'origine----- De : ipv6-wg-bounces@ripe.net [mailto:ipv6-wg-bounces@ripe.net] De la part de MarcoH Envoyé : lundi 14 octobre 2013 10:19 À : Roger Jørgensen Cc : ipv6-wg@ripe.net IPv6 Objet : Re: [ipv6-wg] IPv6 Only Network at RIPE 67
The easy answer is " that is why we run this test". Unfortunate to hear Android doesn't work, hopefully somebody is able to correct this based on reports like this.
MarcoH -- Sent from mobile, sorry for the typos
On 14 okt. 2013, at 10:41, Roger Jørgensen <rogerj@gmail.com> wrote:
On Sun, Oct 13, 2013 at 12:04 PM, Marco Hogewoning <marcoh@marcoh.net> wrote: <snip>
We encourage everybody to connect to this network and test any websites, applications, hardware and software, and verify that they operate when an IPv4 address is no longer available.
Windows 7 had some initial issues, think the initial issue was more of a timing/timeout issue when I moved from a regular IPv4 SSID over to IPv6 only. Seemed like win7 expected IPv4 and when it got none it considered the SSID as failed and moved on. After a disconnect, poweroff/on wifi and then reconnect it connected just fine.
Android on the other hand failed horrible with IPv6 only, (Android 4.0.*/4.2 and 4.3), it expect IPv4 and when it don't get it after a while it move on to the next SSID it can connect to.
--
Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no
________________________________
L'intégrité de ce message n'étant pas assurée sur internet, la société expéditrice ne peut être tenue responsable de son contenu ni de ses pièces jointes. Toute utilisation ou diffusion non autorisée est interdite. Si vous n'êtes pas destinataire de ce message, merci de le détruire et d'avertir l'expéditeur.
The integrity of this message cannot be guaranteed on the Internet. The company that sent this message cannot therefore be held liable for its content nor attachments. Any unauthorized use or dissemination is prohibited. If you are not the intended recipient of this message, then please delete it and notify the sender.
* MarcoH
The easy answer is " that is why we run this test". Unfortunate to hear Android doesn't work, hopefully somebody is able to correct this based on reports like this.
I submitted https://code.google.com/p/android/issues/detail?id=32630 well over a year ago, still no owner... Tore
On Mon, Oct 14, 2013 at 3:18 PM, Tore Anderson <tore@fud.no> wrote:
* MarcoH
The easy answer is " that is why we run this test". Unfortunate to hear Android doesn't work, hopefully somebody is able to correct this based on reports like this.
I submitted https://code.google.com/p/android/issues/detail?id=32630 well over a year ago, still no owner...
thanks for the pointer, I just added another comment to it... guess it's about time they get some noise on this one? -- Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no
Jari Arkko et al wrote an Android dhcpd drop-in replacement http://www.arkko.com/ddd/ a couple of years ago that works. I have no idea why it has not been adopted by droid. ///fredrik :-) IPv6 -Doom of the dots. Rise of the colons:! -----Original Message----- From: ipv6-wg-bounces@ripe.net [mailto:ipv6-wg-bounces@ripe.net] On Behalf Of Tore Anderson Sent: den 14 oktober 2013 15:18 To: MarcoH Cc: ipv6-wg@ripe.net IPv6 Subject: Re: [ipv6-wg] IPv6 Only Network at RIPE 67 * MarcoH
The easy answer is " that is why we run this test". Unfortunate to hear Android doesn't work, hopefully somebody is able to correct this based on reports like this.
I submitted https://code.google.com/p/android/issues/detail?id=32630 well over a year ago, still no owner... Tore
On Mon, Oct 14, 2013 at 9:41 AM, Roger Jørgensen <rogerj@gmail.com> wrote:
Android on the other hand failed horrible with IPv6 only, (Android 4.0.*/4.2 and 4.3), it expect IPv4 and when it don't get it after a while it move on to the next SSID it can connect to.
Yeah, known issue. However it works perfectly fine for me (Android 4.3) since I applied a workaround (static v4 and DNS config). Tested all applications I normally use on my phone. -- SY, Jen Linkova aka Furry
* Jen Linkova
On Mon, Oct 14, 2013 at 9:41 AM, Roger Jørgensen <rogerj@gmail.com> wrote:
Android on the other hand failed horrible with IPv6 only, (Android 4.0.*/4.2 and 4.3), it expect IPv4 and when it don't get it after a while it move on to the next SSID it can connect to.
Yeah, known issue. However it works perfectly fine for me (Android 4.3) since I applied a workaround (static v4 and DNS config). Tested all applications I normally use on my phone.
Yes, this works for me too. However the 464XLAT functionality does not get enabled, presumably because the bogus static placeholder IPv4 configuration fools it into thinking that there is no need for it. Not that I expected this to work to begin with... Tore
Hi, I Test Little Bit with: Iphone 5 Ios 7.0.2 Connect: ok Browsing: ok Facebook app: Not ok Facebook Messenger: Not ok Whatsapp: Not ok Googlemail (over iphone Mail): Not ok Dicct.cc: ok (spell Sounds) Apple iMessage: Not ok Ripestat app: ok ;) Mc donalds app: Not ok Regards, Andreas Send from iPhone
Am 13.10.2013 um 13:05 schrieb "Marco Hogewoning" <marcoh@marcoh.net>:
"It's an IPv6 Working Group Initiative!"
Dear Colleagues,
Following the discussion at RIPE 66, the IPv6 Working Group is happy to provide you with an experimental network that is configured to offer only IPv6. This experimental network is not supported by the RIPE NCC or RIPE 67 Technical Team.
We encourage everybody to connect to this network and test any websites, applications, hardware and software, and verify that they operate when an IPv4 address is no longer available.
Important: This network is an experiment and is offered on a best-effort basis. We will try to maintain sufficient service levels and are happy to look into and help troubleshoot any issues you may encounter. If you rely on network connectivity for important business, we recommend you connect to the regular RIPE Meeting network.
How to connect:
- Make sure IPv6 is enabled on your device - Connect to SSID: IPV6ONLYEXP - Enter the password: iknowbesteffort
The network provides NAT64 translation to connect to legacy services – please use the name server provided by the network to make use of this feature. We suggest you leave IPv4 enabled as this will be the scenario for most end users.
Feedback:
Please see Marco Hogewoning or Andrew Yourtchenko for any issues.
We invite you to attend the IPv6 Working Group session on Thursday from 9:00-10:30 to discuss the results of this experiment. And of course you are welcome to follow up on this mailing list.
Greetings,
Marco Hogewoning Andrew Yourtchenko
Finally I've found a site which does not work ;-) https://tools.cisco.com/RPFA/passwordreset.do?exit_url=http://www.cisco.com/ "We are sorry but analysis of your internet protocol (IP) address does not permit us to complete your Cisco registration at this time. Your IP address is coming across to us in an invalid format." Lovely ;) On Sun, Oct 13, 2013 at 12:04 PM, Marco Hogewoning <marcoh@marcoh.net> wrote:
"It's an IPv6 Working Group Initiative!"
Dear Colleagues,
Following the discussion at RIPE 66, the IPv6 Working Group is happy to provide you with an experimental network that is configured to offer only IPv6. This experimental network is not supported by the RIPE NCC or RIPE 67 Technical Team.
We encourage everybody to connect to this network and test any websites, applications, hardware and software, and verify that they operate when an IPv4 address is no longer available.
Important: This network is an experiment and is offered on a best-effort basis. We will try to maintain sufficient service levels and are happy to look into and help troubleshoot any issues you may encounter. If you rely on network connectivity for important business, we recommend you connect to the regular RIPE Meeting network.
How to connect:
- Make sure IPv6 is enabled on your device - Connect to SSID: IPV6ONLYEXP - Enter the password: iknowbesteffort
The network provides NAT64 translation to connect to legacy services – please use the name server provided by the network to make use of this feature. We suggest you leave IPv4 enabled as this will be the scenario for most end users.
Feedback:
Please see Marco Hogewoning or Andrew Yourtchenko for any issues.
We invite you to attend the IPv6 Working Group session on Thursday from 9:00-10:30 to discuss the results of this experiment. And of course you are welcome to follow up on this mailing list.
Greetings,
Marco Hogewoning Andrew Yourtchenko
-- SY, Jen Linkova aka Furry
Thanks, can I use this screenshot in my presentation on Thursday? Grtx, MarcoH -- "Life is like riding a bicycle. To keep your balance you must keep moving" -- Albert Einstein On Oct 16, 2013, at 11:03 AM, Jen Linkova <furry13@gmail.com> wrote:
Finally I've found a site which does not work ;-)
https://tools.cisco.com/RPFA/passwordreset.do?exit_url=http://www.cisco.com/
"We are sorry but analysis of your internet protocol (IP) address does not permit us to complete your Cisco registration at this time.
Your IP address is coming across to us in an invalid format."
Lovely ;)
On Sun, Oct 13, 2013 at 12:04 PM, Marco Hogewoning <marcoh@marcoh.net> wrote:
"It's an IPv6 Working Group Initiative!"
Dear Colleagues,
Following the discussion at RIPE 66, the IPv6 Working Group is happy to provide you with an experimental network that is configured to offer only IPv6. This experimental network is not supported by the RIPE NCC or RIPE 67 Technical Team.
We encourage everybody to connect to this network and test any websites, applications, hardware and software, and verify that they operate when an IPv4 address is no longer available.
Important: This network is an experiment and is offered on a best-effort basis. We will try to maintain sufficient service levels and are happy to look into and help troubleshoot any issues you may encounter. If you rely on network connectivity for important business, we recommend you connect to the regular RIPE Meeting network.
How to connect:
- Make sure IPv6 is enabled on your device - Connect to SSID: IPV6ONLYEXP - Enter the password: iknowbesteffort
The network provides NAT64 translation to connect to legacy services – please use the name server provided by the network to make use of this feature. We suggest you leave IPv4 enabled as this will be the scenario for most end users.
Feedback:
Please see Marco Hogewoning or Andrew Yourtchenko for any issues.
We invite you to attend the IPv6 Working Group session on Thursday from 9:00-10:30 to discuss the results of this experiment. And of course you are welcome to follow up on this mailing list.
Greetings,
Marco Hogewoning Andrew Yourtchenko
-- SY, Jen Linkova aka Furry <cco.png>
On Wed, Oct 16, 2013 at 10:05 AM, Marco Hogewoning <marcoh@marcoh.net> wrote:
Thanks, can I use this screenshot in my presentation on Thursday?
Sure, can not see any problem with it.
On Oct 16, 2013, at 11:03 AM, Jen Linkova <furry13@gmail.com> wrote:
Finally I've found a site which does not work ;-)
https://tools.cisco.com/RPFA/passwordreset.do?exit_url=http://www.cisco.com/
"We are sorry but analysis of your internet protocol (IP) address does not permit us to complete your Cisco registration at this time.
Your IP address is coming across to us in an invalid format."
Lovely ;)
On Sun, Oct 13, 2013 at 12:04 PM, Marco Hogewoning <marcoh@marcoh.net> wrote:
"It's an IPv6 Working Group Initiative!"
Dear Colleagues,
Following the discussion at RIPE 66, the IPv6 Working Group is happy to provide you with an experimental network that is configured to offer only IPv6. This experimental network is not supported by the RIPE NCC or RIPE 67 Technical Team.
We encourage everybody to connect to this network and test any websites, applications, hardware and software, and verify that they operate when an IPv4 address is no longer available.
Important: This network is an experiment and is offered on a best-effort basis. We will try to maintain sufficient service levels and are happy to look into and help troubleshoot any issues you may encounter. If you rely on network connectivity for important business, we recommend you connect to the regular RIPE Meeting network.
How to connect:
- Make sure IPv6 is enabled on your device - Connect to SSID: IPV6ONLYEXP - Enter the password: iknowbesteffort
The network provides NAT64 translation to connect to legacy services – please use the name server provided by the network to make use of this feature. We suggest you leave IPv4 enabled as this will be the scenario for most end users.
Feedback:
Please see Marco Hogewoning or Andrew Yourtchenko for any issues.
We invite you to attend the IPv6 Working Group session on Thursday from 9:00-10:30 to discuss the results of this experiment. And of course you are welcome to follow up on this mailing list.
Greetings,
Marco Hogewoning Andrew Yourtchenko
-- SY, Jen Linkova aka Furry <cco.png>
-- SY, Jen Linkova aka Furry
Known issue apparently... Got reply from the support: "Cisco.com error code IP101 occurs whenever connecting to Cisco.com using an IPV6 address while resetting a password or registering on Cisco.com. Cisco is aware of this issue and a development team is working on a permanent fix. As a workaround, please use an IPV4 address and refer to your internal IT for questions on how to enable an IPV4." On Wed, Oct 16, 2013 at 10:03 AM, Jen Linkova <furry13@gmail.com> wrote:
Finally I've found a site which does not work ;-)
https://tools.cisco.com/RPFA/passwordreset.do?exit_url=http://www.cisco.com/
"We are sorry but analysis of your internet protocol (IP) address does not permit us to complete your Cisco registration at this time.
Your IP address is coming across to us in an invalid format."
Lovely ;)
On Sun, Oct 13, 2013 at 12:04 PM, Marco Hogewoning <marcoh@marcoh.net> wrote:
"It's an IPv6 Working Group Initiative!"
Dear Colleagues,
Following the discussion at RIPE 66, the IPv6 Working Group is happy to provide you with an experimental network that is configured to offer only IPv6. This experimental network is not supported by the RIPE NCC or RIPE 67 Technical Team.
We encourage everybody to connect to this network and test any websites, applications, hardware and software, and verify that they operate when an IPv4 address is no longer available.
Important: This network is an experiment and is offered on a best-effort basis. We will try to maintain sufficient service levels and are happy to look into and help troubleshoot any issues you may encounter. If you rely on network connectivity for important business, we recommend you connect to the regular RIPE Meeting network.
How to connect:
- Make sure IPv6 is enabled on your device - Connect to SSID: IPV6ONLYEXP - Enter the password: iknowbesteffort
The network provides NAT64 translation to connect to legacy services – please use the name server provided by the network to make use of this feature. We suggest you leave IPv4 enabled as this will be the scenario for most end users.
Feedback:
Please see Marco Hogewoning or Andrew Yourtchenko for any issues.
We invite you to attend the IPv6 Working Group session on Thursday from 9:00-10:30 to discuss the results of this experiment. And of course you are welcome to follow up on this mailing list.
Greetings,
Marco Hogewoning Andrew Yourtchenko
-- SY, Jen Linkova aka Furry
-- SY, Jen Linkova aka Furry
On 16/10/2013 11:32 πμ, Jen Linkova wrote:
Known issue apparently...
Got reply from the support:
"Cisco.com error code IP101 occurs whenever connecting to Cisco.com using an IPV6 address while resetting a password or registering on Cisco.com. Cisco is aware of this issue and a development team is working on a permanent fix.
As a workaround, please use an IPV4 address and refer to your internal IT for questions on how to enable an IPV4."
I would have never thought that we would reach such a point in time, where we would be given instructions on how to enable ipv4... -- Tassos
On Wed, Oct 16, 2013 at 10:03 AM, Jen Linkova <furry13@gmail.com> wrote:
Finally I've found a site which does not work ;-)
https://tools.cisco.com/RPFA/passwordreset.do?exit_url=http://www.cisco.com/
"We are sorry but analysis of your internet protocol (IP) address does not permit us to complete your Cisco registration at this time.
Your IP address is coming across to us in an invalid format."
Lovely ;)
On Sun, Oct 13, 2013 at 12:04 PM, Marco Hogewoning <marcoh@marcoh.net> wrote:
"It's an IPv6 Working Group Initiative!"
Dear Colleagues,
Following the discussion at RIPE 66, the IPv6 Working Group is happy to provide you with an experimental network that is configured to offer only IPv6. This experimental network is not supported by the RIPE NCC or RIPE 67 Technical Team.
We encourage everybody to connect to this network and test any websites, applications, hardware and software, and verify that they operate when an IPv4 address is no longer available.
Important: This network is an experiment and is offered on a best-effort basis. We will try to maintain sufficient service levels and are happy to look into and help troubleshoot any issues you may encounter. If you rely on network connectivity for important business, we recommend you connect to the regular RIPE Meeting network.
How to connect:
- Make sure IPv6 is enabled on your device - Connect to SSID: IPV6ONLYEXP - Enter the password: iknowbesteffort
The network provides NAT64 translation to connect to legacy services – please use the name server provided by the network to make use of this feature. We suggest you leave IPv4 enabled as this will be the scenario for most end users.
Feedback:
Please see Marco Hogewoning or Andrew Yourtchenko for any issues.
We invite you to attend the IPv6 Working Group session on Thursday from 9:00-10:30 to discuss the results of this experiment. And of course you are welcome to follow up on this mailing list.
Greetings,
Marco Hogewoning Andrew Yourtchenko
-- SY, Jen Linkova aka Furry
F5 SSL/VPN client doesn't seem to work. It gets stuck while authenticating... -- Tassos
On Wed, Oct 16, 2013 at 1:03 PM, Tassos Chatzithomaoglou <achatz@forthnetgroup.gr> wrote:
F5 SSL/VPN client doesn't seem to work. It gets stuck while authenticating...
Oh yes, we can add OpenVPN to the list of things which are broken but I have not looked closely.. -- SY, Jen Linkova aka Furry
Hi, On Wed, Oct 16, 2013 at 01:30:30PM +0200, Jen Linkova wrote:
On Wed, Oct 16, 2013 at 1:03 PM, Tassos Chatzithomaoglou <achatz@forthnetgroup.gr> wrote:
F5 SSL/VPN client doesn't seem to work. It gets stuck while authenticating...
Oh yes, we can add OpenVPN to the list of things which are broken but I have not looked closely..
*wake up*. OpenVPN IPv6 development team here :-) - what's breaking for you? (I can't actually test it myself, as the laptop I have with me is too old to reasonably use the IPv6-only network - long story - but I'm happy to work with you to see what breaks in OpenVPN. It really should work, *unless* you route your ipv6 endpoint into the tunnel. Known shortcoming on the unix and windows client, the iOS client handles that) Gert Doering -- OpenVPN IPv6 wrangler -- 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
* Gert Doering
*wake up*. OpenVPN IPv6 development team here :-) - what's breaking for you?
I'm successfully using OpenVPN on the IPv6-only LAN. However there are a few caveats: 1) I need move /usr/sbin/openvpn aside and replace it with a wrapper script that substitutes "udp" and "tcp-client" with "udp6" and "tcp6-server" in the arguments list before exec-ing the real binary. This is because NetworkManager doesn't support the explicit IPv6 protocol definitions, and likely never will either as they are likely going away in the future. 2) I need to use TCP, because the server at work does not support UDP/IPv6 because enabling that in turn breaks --multihome for IPv4 clients: https://community.openvpn.net/openvpn/ticket/306 3) The OpenVPN server pushes a DNS server which gets higher priority than the DNS64 one here, which in turn breaks NAT64 and access to IPv4-only content. I found no way to override this in NM-OpenVPN, although I suppose I could do chattr +i /etc/resolv.conf instead... (not saying this is a bug in OpenVPN, more a general caveat when doing VPN from NAT64/DNS64 networks). Tore
Hi, On Wed, Oct 16, 2013 at 04:03:27PM +0300, Tore Anderson wrote:
I'm successfully using OpenVPN on the IPv6-only LAN.
Seconded, using "Android for OpenVPN" and "OpenVPN Connect" on Android (Nexus 7, with the caveat of "needing static IPv4 address and manual DNS config" to make ipv6-only wifi work in the first place), connecting to an IPv6-enabled server (over UDP, server running with --proto udp6). Connecting to a test OpenVPN server that deliberately has only IPv4 in DNS worked as well (udp). So OpenVPN handles NAT64/DNS64 fine, and both the 2.3 and 3.0 code bases work on an IPv6-only network (yay). As expected, connecting using OpenVPN profiles that have IPv4-literals in there ("server 1.2.3.4") fail. Don't do that, then.
However there are a few caveats:
3) The OpenVPN server pushes a DNS server which gets higher priority than the DNS64 one here, which in turn breaks NAT64 and access to IPv4-only content. I found no way to override this in NM-OpenVPN, although I suppose I could do chattr +i /etc/resolv.conf instead... (not saying this is a bug in OpenVPN, more a general caveat when doing VPN from NAT64/DNS64 networks).
In my case, the server does *not* push a DNS server, which means that trying to use the VPN to access *IPv4* hosts *inside* the VPN fails in interesting ways - DNS64 interferes, and due to the way routing is set up, IPv4 hosts *inside* the VPN are now accessed via NAT64 *around* the VPN (my test host - http://v6.de/ - is purposely available over that VPN or without it). So indeed, DNS and VPN interaction is more complex if DNS64/NAT64 is also intermixed, and if you are not redirecting "all IPv4+IPv6 traffic" through the tunnel (redirect-gateway). 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
Gert, am Wed, Oct 16, 2013 at 03:37:01PM +0200 hast du folgendes geschrieben:
As expected, connecting using OpenVPN profiles that have IPv4-literals in there ("server 1.2.3.4") fail. Don't do that, then.
there is one instance where this is actually needed: if split DNS is in use and the resolvers are not available from outside the tunnel and if you're on Linux (the latter is a guess, and I only tested with resolvconf present). In this case, when the client loses its tunnel, the DNS servers are not reset to the non-VPN ones. OpenVPN will do a fresh DNS lookup for the VPN server to a now unreachable DNS server, which fails. Hence the tunnel will not come back up. That's the reason why we opted for IPv4 literals in the OpenVPN deployment at my alma mater. Kind regards Philipp Kern
Hi, just for the record, as this is veering wildly off the original topic... On Thu, Oct 17, 2013 at 08:57:28PM +0200, Philipp Kern wrote:
As expected, connecting using OpenVPN profiles that have IPv4-literals in there ("server 1.2.3.4") fail. Don't do that, then.
there is one instance where this is actually needed: if split DNS is in use and the resolvers are not available from outside the tunnel and if you're on Linux (the latter is a guess, and I only tested with resolvconf present).
In this case, when the client loses its tunnel, the DNS servers are not reset to the non-VPN ones. OpenVPN will do a fresh DNS lookup for the VPN server to a now unreachable DNS server, which fails. Hence the tunnel will not come back up.
That's the reason why we opted for IPv4 literals in the OpenVPN deployment at my alma mater.
I can only strongly recommend against that, again. It will break your OpenVPN setup on mobile devices that sit behind a NAT64/DNS64, while OpenVPN would otherwise work perfectly well, connecting from an IPv6- capable client to an IPv4-only OpenVPN server - and it will also impair connectivity if you happen to dual-stack the server later (because you'll need to roll out new certificates). I'll go testing why the DNS settings are not restored if the tunnel breaks down, while at the same time doing a fresh DNS lookup - that sounds like a bug to me, as it can't work, obviously. OTOH the whole "change DNS while OpenVPN is running" is a bit wacky on *Linux*, as it's done by distribution-specific external scripts... I'm happy to continue that discussion over at the openvpn-devel list (@lists.sourceforge.net), though :-) 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 Oct 16, 2013, at 2:36 PM, Gert Doering <gert@space.net> wrote:
Oh yes, we can add OpenVPN to the list of things which are broken but I have not looked closely..
*wake up*. OpenVPN IPv6 development team here :-) - what's breaking for you?
I had one user who had OpenVPN overriding the DNS resolver setting, which breaks NAT64 and in turn breaks everything else (including the VPN). Marco
Hi, On Wed, Oct 16, 2013 at 04:11:38PM +0300, Marco Hogewoning wrote:
On Oct 16, 2013, at 2:36 PM, Gert Doering <gert@space.net> wrote:
Oh yes, we can add OpenVPN to the list of things which are broken but I have not looked closely..
*wake up*. OpenVPN IPv6 development team here :-) - what's breaking for you?
I had one user who had OpenVPN overriding the DNS resolver setting, which breaks NAT64 and in turn breaks everything else (including the VPN).
It will break NAT64 while the VPN is up, but it should not break the VPN itself (as the DNS settings *should* be restored when the VPN ends, and while it's up, it will not look at DNS). What platform was this on, and which "gui bundle"? As mentioned, there's a few different versions floating around (2.1, 2.3+ and 3.0 code basis). 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
I had one user who had OpenVPN overriding the DNS resolver setting, which breaks NAT64 and in turn breaks everything else (including the VPN).
It will break NAT64 while the VPN is up, but it should not break the VPN itself (as the DNS settings *should* be restored when the VPN ends, and while it's up, it will not look at DNS).
It should have had a '?' it was just my guess that it would end up with killing the VPN as well Maco
* Gert Doering
On Wed, Oct 16, 2013 at 04:11:38PM +0300, Marco Hogewoning wrote:
I had one user who had OpenVPN overriding the DNS resolver setting, which breaks NAT64 and in turn breaks everything else (including the VPN).
It will break NAT64 while the VPN is up, but it should not break the VPN itself (as the DNS settings *should* be restored when the VPN ends, and while it's up, it will not look at DNS).
What platform was this on, and which "gui bundle"? As mentioned, there's a few different versions floating around (2.1, 2.3+ and 3.0 code basis).
I think Marco is referring to a tweet I made, but I did not mean to say that the VPN breaks. It does not. It's just the VPN pre-empts the DNS64, and since only specific (my) IPv4/IPv6 networks are pushed by the VPN, this means that I can no longer reach IPv4-only content on the internet (IPv4-only content in my own network works fine, through the VPN, and all IPv6 content is also fine - through the VPN for my own networks, or directly for the rest of the internet). I didn't try contacting the OpenVPN server through the NAT64 (native IPv6 in both the server and client end now), but I could try that as well. I don't expect it to fail though, so unless you hear anything to the contrary, assume it worked fine. Tore
Hi, On Wed, Oct 16, 2013 at 01:30:30PM +0200, Jen Linkova wrote:
Oh yes, we can add OpenVPN to the list of things which are broken but I have not looked closely..
Just a small update on that: OpenVPN can be a bit confusing at times - there is "OpenVPN the open source project, which is a *cli* program, which should work over IPv6 transport just fine since version 2.3.0" and "OpenVPN bundled with a GUI, hiding the cli program somewhere in the back". On MacOS, there's at least 3 different versions of the Gui - Tunnelblick (open source, comes with openvpn core 2.2 and 2.3 "inside", selectable using options), and "OpenVPN connect", which is the commercially backed client... which is nicely packaging everything, and, unfortunately, hiding the logs somewhere so I couldn't find out yet why it's misbehaving. ... will get the answer for you :-) (On Android, both clients - OpenVPN for Android and OpenVPN Connect - *should* work fine from the IPv6-only network... - same for OpenVPN on iOS. If not, I'd like to hear more about it :-) ) Gert Doering -- OpenVPN wrangler -- 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
Just to clarify my initial statement, when i said the F5 vpn/ssl client doesn't work, i meant it doesn't work for an ipv4 destination, so it's probably a thing with nat64 and ssl. I don't know if this is the case with openvpn too. -- Tassos On 16/10/2013 3:44 μμ, Gert Doering wrote:
Hi,
Oh yes, we can add OpenVPN to the list of things which are broken but I have not looked closely.. Just a small update on that: OpenVPN can be a bit confusing at times -
On Wed, Oct 16, 2013 at 01:30:30PM +0200, Jen Linkova wrote: there is "OpenVPN the open source project, which is a *cli* program, which should work over IPv6 transport just fine since version 2.3.0" and "OpenVPN bundled with a GUI, hiding the cli program somewhere in the back".
On MacOS, there's at least 3 different versions of the Gui - Tunnelblick (open source, comes with openvpn core 2.2 and 2.3 "inside", selectable using options), and "OpenVPN connect", which is the commercially backed client... which is nicely packaging everything, and, unfortunately, hiding the logs somewhere so I couldn't find out yet why it's misbehaving.
... will get the answer for you :-)
(On Android, both clients - OpenVPN for Android and OpenVPN Connect - *should* work fine from the IPv6-only network... - same for OpenVPN on iOS. If not, I'd like to hear more about it :-) )
Gert Doering -- OpenVPN wrangler
F5 SSL/VPN client doesn't seem to work. It gets stuck while authenticating...
I also use it and ran into two problems, running it on 10.8.5 - if you explicitly switch off IPv4, it will authenticate but right away disconnect again. My guess is that it is trying to install an IPv4 route, which is denied by the OS and cause it to drop the link - With IPv4 enabled, it does connect and works fine but after 10 mins it panics about the connection being dropped I haven't been able to fully debug, but I suspect that this has to do with the self-assigned IPv4 address on the interface. I think that the moment the OS tries again in obtaining an IP address, the IPv4 side of the interface gets cleared and that causes the client to think the internet connection went away. Marco
participants (12)
-
Fredrik Garneij -
Gert Doering -
HOFFMANN, Lionel -
Jen Linkova -
Koch Andreas -
Marco Hogewoning -
MarcoH
-
Philipp Kern -
Roger Jørgensen -
TACHIBANA toshio -
Tassos Chatzithomaoglou -
Tore Anderson