From mir at ripe.net Wed Oct 2 16:49:45 2013 From: mir at ripe.net (Mirjam Kuehne) Date: Wed, 02 Oct 2013 16:49:45 +0200 Subject: [ipv6-wg] New on RIPE Labs: RIPE Atlas - Packet Size Matters Message-ID: <524C3289.3060900@ripe.net> Dear colleagues, This new RIPE Labs article (contributed by Emile Aben) talks about trying to send large packets over the Internet. Above a certain size, these packets will have to be fragmented, which is known to cause problems. In both IPv4 and IPv6, we see approximately 10% of RIPE Atlas probes that are unsuccessful in pings with fragmented packets, while they don't encounter problems with smaller unfragmented packets. Please find the detailed results on RIPE Labs: https://labs.ripe.net/Members/emileaben/ripe-atlas-packet-size-matters Kind regards, Mirjam Kuehne RIPE NCC From marcoh at marcoh.net Sun Oct 13 12:04:13 2013 From: marcoh at marcoh.net (Marco Hogewoning) Date: Sun, 13 Oct 2013 13:04:13 +0300 Subject: [ipv6-wg] IPv6 Only Network at RIPE 67 Message-ID: "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 From rogerj at gmail.com Mon Oct 14 09:41:00 2013 From: rogerj at gmail.com (=?ISO-8859-1?Q?Roger_J=F8rgensen?=) Date: Mon, 14 Oct 2013 09:41:00 +0200 Subject: [ipv6-wg] IPv6 Only Network at RIPE 67 In-Reply-To: References: Message-ID: On Sun, Oct 13, 2013 at 12:04 PM, Marco Hogewoning wrote: > 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 at gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no From marcoh at marcoh.net Mon Oct 14 10:18:58 2013 From: marcoh at marcoh.net (MarcoH) Date: Mon, 14 Oct 2013 11:18:58 +0300 Subject: [ipv6-wg] IPv6 Only Network at RIPE 67 In-Reply-To: References: Message-ID: <0A74CD6B-EA49-4BDD-B1CC-D32CA6CBBD3E@marcoh.net> 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 wrote: > On Sun, Oct 13, 2013 at 12:04 PM, Marco Hogewoning wrote: > >> 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 at gmail.com | - IPv6 is The Key! > http://www.jorgensen.no | roger at jorgensen.no From LHOFFMAN at bouyguestelecom.fr Mon Oct 14 11:40:55 2013 From: LHOFFMAN at bouyguestelecom.fr (HOFFMANN, Lionel) Date: Mon, 14 Oct 2013 09:40:55 +0000 Subject: [ipv6-wg] IPv6 Only Network at RIPE 67 In-Reply-To: <0A74CD6B-EA49-4BDD-B1CC-D32CA6CBBD3E@marcoh.net> References: <0A74CD6B-EA49-4BDD-B1CC-D32CA6CBBD3E@marcoh.net> Message-ID: <035526E98A5F8644A6E7F849F58C9B9224A01517@bt1shktn.bt0d0000.w2k.bouyguestelecom.fr> It seems not better with Ios Lionel HOFFMANN DIRECTION TECHNIQUE Fixe: 01 39 45 42 76 Mobile: 06 60 31 42 76 Email: lhoffman at bouyguestelecom.fr Adresse: 13/15 Avenue du mar?chal Juin 92360 MEUDON -----Message d'origine----- De : ipv6-wg-bounces at ripe.net [mailto:ipv6-wg-bounces at ripe.net] De la part de MarcoH Envoy? : lundi 14 octobre 2013 10:19 ? : Roger J?rgensen Cc : ipv6-wg at 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 wrote: > On Sun, Oct 13, 2013 at 12:04 PM, Marco Hogewoning wrote: > >> 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 at gmail.com | - IPv6 is The Key! > http://www.jorgensen.no | roger at 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. From toshio at aniani.com Mon Oct 14 12:21:56 2013 From: toshio at aniani.com (TACHIBANA toshio) Date: Mon, 14 Oct 2013 19:21:56 +0900 Subject: [ipv6-wg] IPv6 Only Network at RIPE 67 In-Reply-To: <035526E98A5F8644A6E7F849F58C9B9224A01517@bt1shktn.bt0d0000.w2k.bouyguestelecom.fr> References: <0A74CD6B-EA49-4BDD-B1CC-D32CA6CBBD3E@marcoh.net> <035526E98A5F8644A6E7F849F58C9B9224A01517@bt1shktn.bt0d0000.w2k.bouyguestelecom.fr> Message-ID: Facebook Apps said "No Internet Connection" on iPhone4s with iOS7. -- TACHIBANA toshio On Mon, Oct 14, 2013 at 6:40 PM, HOFFMANN, Lionel 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 at bouyguestelecom.fr > Adresse: 13/15 Avenue du mar?chal Juin > 92360 MEUDON > > -----Message d'origine----- > De : ipv6-wg-bounces at ripe.net [mailto:ipv6-wg-bounces at ripe.net] De la part de MarcoH > Envoy? : lundi 14 octobre 2013 10:19 > ? : Roger J?rgensen > Cc : ipv6-wg at 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 wrote: > >> On Sun, Oct 13, 2013 at 12:04 PM, Marco Hogewoning wrote: >> >>> 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 at gmail.com | - IPv6 is The Key! >> http://www.jorgensen.no | roger at 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. From marcoh at marcoh.net Mon Oct 14 13:08:45 2013 From: marcoh at marcoh.net (Marco Hogewoning) Date: Mon, 14 Oct 2013 14:08:45 +0300 Subject: [ipv6-wg] IPv6 Only Network at RIPE 67 In-Reply-To: References: <0A74CD6B-EA49-4BDD-B1CC-D32CA6CBBD3E@marcoh.net> <035526E98A5F8644A6E7F849F58C9B9224A01517@bt1shktn.bt0d0000.w2k.bouyguestelecom.fr> Message-ID: 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 wrote: > Facebook Apps said "No Internet Connection" on iPhone4s with iOS7. > > -- > TACHIBANA toshio > > On Mon, Oct 14, 2013 at 6:40 PM, HOFFMANN, Lionel > 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 at bouyguestelecom.fr >> Adresse: 13/15 Avenue du mar?chal Juin >> 92360 MEUDON >> >> -----Message d'origine----- >> De : ipv6-wg-bounces at ripe.net [mailto:ipv6-wg-bounces at ripe.net] De la part de MarcoH >> Envoy? : lundi 14 octobre 2013 10:19 >> ? : Roger J?rgensen >> Cc : ipv6-wg at 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 wrote: >> >>> On Sun, Oct 13, 2013 at 12:04 PM, Marco Hogewoning wrote: >>> >>>> 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 at gmail.com | - IPv6 is The Key! >>> http://www.jorgensen.no | roger at 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. > From marcoh at marcoh.net Mon Oct 14 13:09:10 2013 From: marcoh at marcoh.net (Marco Hogewoning) Date: Mon, 14 Oct 2013 14:09:10 +0300 Subject: [ipv6-wg] IPv6 Only Network at RIPE 67 In-Reply-To: References: <0A74CD6B-EA49-4BDD-B1CC-D32CA6CBBD3E@marcoh.net> <035526E98A5F8644A6E7F849F58C9B9224A01517@bt1shktn.bt0d0000.w2k.bouyguestelecom.fr> Message-ID: <1ACD2350-AB92-40C3-A921-C1828725E39A@marcoh.net> 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 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 wrote: >> Facebook Apps said "No Internet Connection" on iPhone4s with iOS7. >> >> -- >> TACHIBANA toshio >> >> On Mon, Oct 14, 2013 at 6:40 PM, HOFFMANN, Lionel >> 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 at bouyguestelecom.fr >>> Adresse: 13/15 Avenue du mar?chal Juin >>> 92360 MEUDON >>> >>> -----Message d'origine----- >>> De : ipv6-wg-bounces at ripe.net [mailto:ipv6-wg-bounces at ripe.net] De la part de MarcoH >>> Envoy? : lundi 14 octobre 2013 10:19 >>> ? : Roger J?rgensen >>> Cc : ipv6-wg at 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 wrote: >>> >>>> On Sun, Oct 13, 2013 at 12:04 PM, Marco Hogewoning wrote: >>>> >>>>> 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 at gmail.com | - IPv6 is The Key! >>>> http://www.jorgensen.no | roger at 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 From furry13 at gmail.com Mon Oct 14 13:04:24 2013 From: furry13 at gmail.com (Jen Linkova) Date: Mon, 14 Oct 2013 13:04:24 +0200 Subject: [ipv6-wg] IPv6 Only Network at RIPE 67 In-Reply-To: References: <0A74CD6B-EA49-4BDD-B1CC-D32CA6CBBD3E@marcoh.net> <035526E98A5F8644A6E7F849F58C9B9224A01517@bt1shktn.bt0d0000.w2k.bouyguestelecom.fr> Message-ID: 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 wrote: > Facebook Apps said "No Internet Connection" on iPhone4s with iOS7. > > -- > TACHIBANA toshio > > On Mon, Oct 14, 2013 at 6:40 PM, HOFFMANN, Lionel > 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 at bouyguestelecom.fr >> Adresse: 13/15 Avenue du mar?chal Juin >> 92360 MEUDON >> >> -----Message d'origine----- >> De : ipv6-wg-bounces at ripe.net [mailto:ipv6-wg-bounces at ripe.net] De la part de MarcoH >> Envoy? : lundi 14 octobre 2013 10:19 >> ? : Roger J?rgensen >> Cc : ipv6-wg at 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 wrote: >> >>> On Sun, Oct 13, 2013 at 12:04 PM, Marco Hogewoning wrote: >>> >>>> 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 at gmail.com | - IPv6 is The Key! >>> http://www.jorgensen.no | roger at 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 From marcoh at marcoh.net Mon Oct 14 13:16:04 2013 From: marcoh at marcoh.net (Marco Hogewoning) Date: Mon, 14 Oct 2013 14:16:04 +0300 Subject: [ipv6-wg] IPv6 Only Network at RIPE 67 In-Reply-To: References: <0A74CD6B-EA49-4BDD-B1CC-D32CA6CBBD3E@marcoh.net> <035526E98A5F8644A6E7F849F58C9B9224A01517@bt1shktn.bt0d0000.w2k.bouyguestelecom.fr> Message-ID: 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 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 wrote: >> Facebook Apps said "No Internet Connection" on iPhone4s with iOS7. >> >> -- >> TACHIBANA toshio >> >> On Mon, Oct 14, 2013 at 6:40 PM, HOFFMANN, Lionel >> 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 at bouyguestelecom.fr >>> Adresse: 13/15 Avenue du mar?chal Juin >>> 92360 MEUDON >>> >>> -----Message d'origine----- >>> De : ipv6-wg-bounces at ripe.net [mailto:ipv6-wg-bounces at ripe.net] De la part de MarcoH >>> Envoy? : lundi 14 octobre 2013 10:19 >>> ? : Roger J?rgensen >>> Cc : ipv6-wg at 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 wrote: >>> >>>> On Sun, Oct 13, 2013 at 12:04 PM, Marco Hogewoning wrote: >>>> >>>>> 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 at gmail.com | - IPv6 is The Key! >>>> http://www.jorgensen.no | roger at 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 > From marcoh at marcoh.net Mon Oct 14 13:24:28 2013 From: marcoh at marcoh.net (Marco Hogewoning) Date: Mon, 14 Oct 2013 14:24:28 +0300 Subject: [ipv6-wg] IPv6 Only Network at RIPE 67 In-Reply-To: References: <0A74CD6B-EA49-4BDD-B1CC-D32CA6CBBD3E@marcoh.net> <035526E98A5F8644A6E7F849F58C9B9224A01517@bt1shktn.bt0d0000.w2k.bouyguestelecom.fr> Message-ID: <9801D978-2206-424C-9C51-FB09F3B9D1B6@marcoh.net> We should back online, come to the IPv6 Working Group on Thursday for I'm sure an interesting incident report. Marco From rogerj at gmail.com Mon Oct 14 15:28:49 2013 From: rogerj at gmail.com (=?ISO-8859-1?Q?Roger_J=F8rgensen?=) Date: Mon, 14 Oct 2013 15:28:49 +0200 Subject: [ipv6-wg] IPv6 Only Network at RIPE 67 In-Reply-To: <525BEF15.7020400@fud.no> References: <0A74CD6B-EA49-4BDD-B1CC-D32CA6CBBD3E@marcoh.net> <525BEF15.7020400@fud.no> Message-ID: On Mon, Oct 14, 2013 at 3:18 PM, Tore Anderson 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 at gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no From tore at fud.no Mon Oct 14 15:18:13 2013 From: tore at fud.no (Tore Anderson) Date: Mon, 14 Oct 2013 15:18:13 +0200 Subject: [ipv6-wg] IPv6 Only Network at RIPE 67 In-Reply-To: <0A74CD6B-EA49-4BDD-B1CC-D32CA6CBBD3E@marcoh.net> References: <0A74CD6B-EA49-4BDD-B1CC-D32CA6CBBD3E@marcoh.net> Message-ID: <525BEF15.7020400@fud.no> * 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 From a.koch at eurodata.de Mon Oct 14 15:41:02 2013 From: a.koch at eurodata.de (Koch Andreas) Date: Mon, 14 Oct 2013 13:41:02 +0000 Subject: [ipv6-wg] IPv6 Only Network at RIPE 67 In-Reply-To: References: Message-ID: 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" : > > "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 > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2147 bytes Desc: not available URL: From fredrik.garneij at ericsson.com Mon Oct 14 15:53:07 2013 From: fredrik.garneij at ericsson.com (Fredrik Garneij) Date: Mon, 14 Oct 2013 13:53:07 +0000 Subject: [ipv6-wg] IPv6 Only Network at RIPE 67 In-Reply-To: <525BEF15.7020400@fud.no> References: <0A74CD6B-EA49-4BDD-B1CC-D32CA6CBBD3E@marcoh.net> <525BEF15.7020400@fud.no> Message-ID: 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 at ripe.net [mailto:ipv6-wg-bounces at ripe.net] On Behalf Of Tore Anderson Sent: den 14 oktober 2013 15:18 To: MarcoH Cc: ipv6-wg at 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 From training at ripe.net Tue Oct 15 14:39:11 2013 From: training at ripe.net (Training Team) Date: Tue, 15 Oct 2013 14:39:11 +0200 Subject: [ipv6-wg] [training] RIPE NCC Webinars - new dates Message-ID: <525D376F.3030002@ripe.net> Dear colleagues, We are pleased to announce the launch of new dates for our Webinars. The RIPE NCC Webinars are live and take only one hour. You can interact with our trainers without leaving your desk. We focus on the topics and issues most important for LIRs. Register now at https://lirportal.ripe.net/training/courses Participation is limited to 20 people, so don't hesitate if you want to take part! If you have questions, please email . We look forward to seeing you online. Kind regards, RIPE NCC Training Services -------------- next part -------------- An HTML attachment was scrubbed... URL: From furry13 at gmail.com Tue Oct 15 15:50:23 2013 From: furry13 at gmail.com (Jen Linkova) Date: Tue, 15 Oct 2013 15:50:23 +0200 Subject: [ipv6-wg] IPv6 Only Network at RIPE 67 In-Reply-To: References: Message-ID: On Mon, Oct 14, 2013 at 9:41 AM, Roger J?rgensen 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 From furry13 at gmail.com Wed Oct 16 10:03:13 2013 From: furry13 at gmail.com (Jen Linkova) Date: Wed, 16 Oct 2013 10:03:13 +0200 Subject: [ipv6-wg] IPv6 Only Network at RIPE 67 In-Reply-To: References: Message-ID: 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 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: cco.png Type: image/png Size: 149287 bytes Desc: not available URL: From marcoh at marcoh.net Wed Oct 16 10:05:20 2013 From: marcoh at marcoh.net (Marco Hogewoning) Date: Wed, 16 Oct 2013 11:05:20 +0300 Subject: [ipv6-wg] IPv6 Only Network at RIPE 67 In-Reply-To: References: Message-ID: <309704D2-8A79-49D5-9C54-954835C787D8@marcoh.net> 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 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 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 > From furry13 at gmail.com Wed Oct 16 10:07:23 2013 From: furry13 at gmail.com (Jen Linkova) Date: Wed, 16 Oct 2013 10:07:23 +0200 Subject: [ipv6-wg] IPv6 Only Network at RIPE 67 In-Reply-To: <309704D2-8A79-49D5-9C54-954835C787D8@marcoh.net> References: <309704D2-8A79-49D5-9C54-954835C787D8@marcoh.net> Message-ID: On Wed, Oct 16, 2013 at 10:05 AM, Marco Hogewoning 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 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 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 From furry13 at gmail.com Wed Oct 16 10:32:34 2013 From: furry13 at gmail.com (Jen Linkova) Date: Wed, 16 Oct 2013 10:32:34 +0200 Subject: [ipv6-wg] IPv6 Only Network at RIPE 67 In-Reply-To: References: Message-ID: 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 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 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 From achatz at forthnetgroup.gr Wed Oct 16 10:51:48 2013 From: achatz at forthnetgroup.gr (Tassos Chatzithomaoglou) Date: Wed, 16 Oct 2013 11:51:48 +0300 Subject: [ipv6-wg] IPv6 Only Network at RIPE 67 In-Reply-To: References: Message-ID: <525E53A4.5010008@forthnetgroup.gr> 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 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 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 > > From achatz at forthnetgroup.gr Wed Oct 16 13:03:40 2013 From: achatz at forthnetgroup.gr (Tassos Chatzithomaoglou) Date: Wed, 16 Oct 2013 14:03:40 +0300 Subject: [ipv6-wg] IPv6 Only Network at RIPE 67 In-Reply-To: <525E53A4.5010008@forthnetgroup.gr> References: <525E53A4.5010008@forthnetgroup.gr> Message-ID: <525E728C.8000505@forthnetgroup.gr> F5 SSL/VPN client doesn't seem to work. It gets stuck while authenticating... -- Tassos From furry13 at gmail.com Wed Oct 16 13:30:30 2013 From: furry13 at gmail.com (Jen Linkova) Date: Wed, 16 Oct 2013 13:30:30 +0200 Subject: [ipv6-wg] IPv6 Only Network at RIPE 67 In-Reply-To: <525E728C.8000505@forthnetgroup.gr> References: <525E53A4.5010008@forthnetgroup.gr> <525E728C.8000505@forthnetgroup.gr> Message-ID: On Wed, Oct 16, 2013 at 1:03 PM, Tassos Chatzithomaoglou 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 From gert at space.net Wed Oct 16 13:36:31 2013 From: gert at space.net (Gert Doering) Date: Wed, 16 Oct 2013 13:36:31 +0200 Subject: [ipv6-wg] IPv6 Only Network at RIPE 67 In-Reply-To: References: <525E53A4.5010008@forthnetgroup.gr> <525E728C.8000505@forthnetgroup.gr> Message-ID: <20131016113631.GH65295@Space.Net> 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 > 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From gert at space.net Wed Oct 16 14:44:49 2013 From: gert at space.net (Gert Doering) Date: Wed, 16 Oct 2013 14:44:49 +0200 Subject: [ipv6-wg] IPv6 Only Network at RIPE 67 In-Reply-To: References: <525E53A4.5010008@forthnetgroup.gr> <525E728C.8000505@forthnetgroup.gr> Message-ID: <20131016124449.GO65295@Space.Net> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From achatz at forthnetgroup.gr Wed Oct 16 14:58:08 2013 From: achatz at forthnetgroup.gr (Tassos Chatzithomaoglou) Date: Wed, 16 Oct 2013 15:58:08 +0300 Subject: [ipv6-wg] IPv6 Only Network at RIPE 67 In-Reply-To: <20131016124449.GO65295@Space.Net> References: <525E53A4.5010008@forthnetgroup.gr> <525E728C.8000505@forthnetgroup.gr> <20131016124449.GO65295@Space.Net> Message-ID: <525E8D60.4040908@forthnetgroup.gr> 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, > > 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 From tore at fud.no Wed Oct 16 15:03:27 2013 From: tore at fud.no (Tore Anderson) Date: Wed, 16 Oct 2013 16:03:27 +0300 Subject: [ipv6-wg] IPv6 Only Network at RIPE 67 In-Reply-To: <20131016113631.GH65295@Space.Net> References: <525E53A4.5010008@forthnetgroup.gr> <525E728C.8000505@forthnetgroup.gr> <20131016113631.GH65295@Space.Net> Message-ID: <525E8E9F.3010209@fud.no> * 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 From marcoh at marcoh.net Wed Oct 16 15:09:58 2013 From: marcoh at marcoh.net (Marco Hogewoning) Date: Wed, 16 Oct 2013 16:09:58 +0300 Subject: [ipv6-wg] IPv6 Only Network at RIPE 67 In-Reply-To: <525E728C.8000505@forthnetgroup.gr> References: <525E53A4.5010008@forthnetgroup.gr> <525E728C.8000505@forthnetgroup.gr> Message-ID: <2A4BA63E-2E49-4FA1-AA00-3C73C9A64696@marcoh.net> > 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 From marcoh at marcoh.net Wed Oct 16 15:11:38 2013 From: marcoh at marcoh.net (Marco Hogewoning) Date: Wed, 16 Oct 2013 16:11:38 +0300 Subject: [ipv6-wg] IPv6 Only Network at RIPE 67 In-Reply-To: <20131016113631.GH65295@Space.Net> References: <525E53A4.5010008@forthnetgroup.gr> <525E728C.8000505@forthnetgroup.gr> <20131016113631.GH65295@Space.Net> Message-ID: On Oct 16, 2013, at 2:36 PM, Gert Doering 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 From gert at space.net Wed Oct 16 15:37:01 2013 From: gert at space.net (Gert Doering) Date: Wed, 16 Oct 2013 15:37:01 +0200 Subject: [ipv6-wg] IPv6 Only Network at RIPE 67 In-Reply-To: <525E8E9F.3010209@fud.no> References: <525E53A4.5010008@forthnetgroup.gr> <525E728C.8000505@forthnetgroup.gr> <20131016113631.GH65295@Space.Net> <525E8E9F.3010209@fud.no> Message-ID: <20131016133701.GP65295@Space.Net> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From gert at space.net Wed Oct 16 15:40:13 2013 From: gert at space.net (Gert Doering) Date: Wed, 16 Oct 2013 15:40:13 +0200 Subject: [ipv6-wg] IPv6 Only Network at RIPE 67 In-Reply-To: References: <525E53A4.5010008@forthnetgroup.gr> <525E728C.8000505@forthnetgroup.gr> <20131016113631.GH65295@Space.Net> Message-ID: <20131016134013.GQ65295@Space.Net> Hi, On Wed, Oct 16, 2013 at 04:11:38PM +0300, Marco Hogewoning wrote: > On Oct 16, 2013, at 2:36 PM, Gert Doering 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From marcoh at marcoh.net Wed Oct 16 15:44:58 2013 From: marcoh at marcoh.net (Marco Hogewoning) Date: Wed, 16 Oct 2013 16:44:58 +0300 Subject: [ipv6-wg] IPv6 Only Network at RIPE 67 In-Reply-To: <20131016134013.GQ65295@Space.Net> References: <525E53A4.5010008@forthnetgroup.gr> <525E728C.8000505@forthnetgroup.gr> <20131016113631.GH65295@Space.Net> <20131016134013.GQ65295@Space.Net> Message-ID: >> 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 From tore at fud.no Wed Oct 16 15:47:45 2013 From: tore at fud.no (Tore Anderson) Date: Wed, 16 Oct 2013 16:47:45 +0300 Subject: [ipv6-wg] IPv6 Only Network at RIPE 67 In-Reply-To: <20131016134013.GQ65295@Space.Net> References: <525E53A4.5010008@forthnetgroup.gr> <525E728C.8000505@forthnetgroup.gr> <20131016113631.GH65295@Space.Net> <20131016134013.GQ65295@Space.Net> Message-ID: <525E9901.1060705@fud.no> * 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 From Ragnar.Anfinsen at altibox.no Wed Oct 16 16:17:51 2013 From: Ragnar.Anfinsen at altibox.no (Anfinsen, Ragnar) Date: Wed, 16 Oct 2013 14:17:51 +0000 Subject: [ipv6-wg] Request for feedback on IETF I-D draft-v6ops-vyncke-balanced-ipv6-security Message-ID: Dear all, The authors would like to invite the community to review and comment on IETF I-D draft-v6ops-vyncke-balanced-ipv6-security. Abstract This document describes how an IPv6 residential Customer Premise Equipment (CPE) can have a balanced security policy that allows for a mostly end-to-end connectivity while keeping the major threats outside of the home. It is based on an actual IPv6 deployment by Swisscom and proposes to allow all packets inbound/outbound EXCEPT for some layer-4 ports where attacks and vulnerabilities (such as weak passwords) are well-known. http://tools.ietf.org/html/draft-v6ops-vyncke-balanced-ipv6-security We have received feedback from the IETF community that there should not be any explicit list of ports to be blocked in the document. The authors feels that this list should be maintained by a neutral internet body, however we need suggestions from the community on who this could be solved. So basically there are a few options on who the list could be managed; * Let the ISP/Vendor define and maintain the list by them selves. * Let the community maintain such list using consensus. * Ask a neutral internet body (insert favorite here) to manage the list based on the actual threat picture. Please keep in mind that this draft is not meant to define an IDS/IPS style of functionality. We are only looking for how to solve the IPv6 firewall default on/off problem. This draft only covers the default list provided when the customer is begin connected. The customer can, depending on the ISP's policy, fully administer the firewall rules. Best Regards The authors; Eric Vyncke, Cisco Martin Gysi, Swisscom Guillaume Leclanche, Swisscom Ragnar Anfinsen, Altibox From tore at fud.no Thu Oct 17 08:32:27 2013 From: tore at fud.no (Tore Anderson) Date: Thu, 17 Oct 2013 09:32:27 +0300 Subject: [ipv6-wg] IPv6 Only Network at RIPE 67 In-Reply-To: References: Message-ID: <525F847B.6000705@fud.no> * Jen Linkova > On Mon, Oct 14, 2013 at 9:41 AM, Roger J?rgensen 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 From phil at philkern.de Thu Oct 17 20:57:28 2013 From: phil at philkern.de (Philipp Kern) Date: Thu, 17 Oct 2013 20:57:28 +0200 Subject: [ipv6-wg] IPv6 Only Network at RIPE 67 In-Reply-To: <20131016133701.GP65295@Space.Net> References: <525E53A4.5010008@forthnetgroup.gr> <525E728C.8000505@forthnetgroup.gr> <20131016113631.GH65295@Space.Net> <525E8E9F.3010209@fud.no> <20131016133701.GP65295@Space.Net> Message-ID: <20131017185728.GA1872@spike.0x539.de> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: From gert at space.net Mon Oct 21 15:40:34 2013 From: gert at space.net (Gert Doering) Date: Mon, 21 Oct 2013 15:40:34 +0200 Subject: [ipv6-wg] IPv6 Only Network at RIPE 67 In-Reply-To: <20131017185728.GA1872@spike.0x539.de> References: <525E53A4.5010008@forthnetgroup.gr> <525E728C.8000505@forthnetgroup.gr> <20131016113631.GH65295@Space.Net> <525E8E9F.3010209@fud.no> <20131016133701.GP65295@Space.Net> <20131017185728.GA1872@spike.0x539.de> Message-ID: <20131021134034.GF50205@Space.Net> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From ripe.ipv6-wg at ml.karotte.org Tue Oct 22 10:58:43 2013 From: ripe.ipv6-wg at ml.karotte.org (Sebastian Wiesinger) Date: Tue, 22 Oct 2013 10:58:43 +0200 Subject: [ipv6-wg] Request for feedback on IETF I-D draft-v6ops-vyncke-balanced-ipv6-security In-Reply-To: References: Message-ID: <20131022085843.GA5193@danton.fire-world.de> * Anfinsen, Ragnar [2013-10-16 16:30]: > Dear all, > > The authors would like to invite the community to review and comment on > IETF I-D draft-v6ops-vyncke-balanced-ipv6-security. > > > Abstract > > This document describes how an IPv6 residential Customer Premise > Equipment (CPE) can have a balanced security policy that allows for a > mostly end-to-end connectivity while keeping the major threats > outside of the home. It is based on an actual IPv6 deployment by > Swisscom and proposes to allow all packets inbound/outbound EXCEPT > for some layer-4 ports where attacks and vulnerabilities (such as > weak passwords) are well-known. > > > http://tools.ietf.org/html/draft-v6ops-vyncke-balanced-ipv6-security > > We have received feedback from the IETF community that there should not be > any explicit list of ports to be blocked in the document. The authors > feels that this list should be maintained by a neutral internet body, > however we need suggestions from the community on who this could be solved. Hello, I can see the advantage in having a mostly-open end-to-end connectivity by default but I don't think it's feasible. Such a list would require a tremendous efford to keep up-to-date and I don't think people would do that. I'm more with the "block inbound by default" crowd. One of the reasons for IPv6 was to have every "smart thing" in the home connect to the Internet. Who wants to gather every vulnerability for every dishwasher and TV that's connecting to the internet? Having said that, I'm bothered by the word "should" in connection with the ability of the enduser to change this list. I would strongly suggest to change that to a MUST everywhere in the document. If I ever get a CPE that doesn't let me choose which ports to open inbound I will go ballistic. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant From shane at time-travellers.org Fri Oct 25 12:37:00 2013 From: shane at time-travellers.org (Shane Kerr) Date: Fri, 25 Oct 2013 12:37:00 +0200 Subject: [ipv6-wg] 96 more bits... time for some magic after all? Message-ID: <20131025123700.07c155ed@earth.home.time-travellers.org> All, [ gah... hit the wrong key and sent this unfinished ] We saw two presentations by network architects at the RIPE meeting that used bits in their IPv6 addressing plan to carry meaning beyond simple network topology and packet routing. For example, declaring a specific bit in the address to be 1 for voice traffic or 0 otherwise. There are motivations for doing this, which may or may not be valid in any particular case. There are ways to lessen the amount of addresses consumed by this (for example by assigning /56 instead of /48 to end users). But I think that the important thing is that we have historically not considered this sort of use with address allocation policy. In face, RFC 2050bis was *just* published as RFC 7020: http://datatracker.ietf.org/doc/rfc7020/ This includes the long-standing historical goals of conservation, aggregation, and accuracy. Using bits in IPv6 networks for other purposes is orthogonal to those goals. What should we do about it? Cheers, -- Shane From shane at time-travellers.org Fri Oct 25 12:35:15 2013 From: shane at time-travellers.org (Shane Kerr) Date: Fri, 25 Oct 2013 12:35:15 +0200 Subject: [ipv6-wg] 96 more bits... time for some magic after all? Message-ID: <20131025123515.1b768c21@earth.home.time-travellers.org> All, We saw two presentations by network architects at the RIPE meeting that used bits in their IPv6 addressing plan to carry meaning beyond simple network topology and packet routing. For example, declaring a specific bit in the address to be 1 for voice traffic or 0 otherwise. There are motivations for doing this, which may or may not be valid in any particular case. There are ways to lessen the amount of addresses consumed by this (for example by assigning /56 instead of /48 to end users). But I think that the important thing is that we have historically not considered this sort of use with address allocation policy. In face, RFC 2050bis was *just* published as RFC 7050: Cheers, -- Shane From jan at pragma.si Fri Oct 25 12:55:56 2013 From: jan at pragma.si (Jan Zorz) Date: Fri, 25 Oct 2013 12:55:56 +0200 Subject: [ipv6-wg] 96 more bits... time for some magic after all? In-Reply-To: <20131025123700.07c155ed@earth.home.time-travellers.org> References: <20131025123700.07c155ed@earth.home.time-travellers.org> Message-ID: <526A4E3C.4070008@pragma.si> On 10/25/13 12:37 PM, Shane Kerr wrote: > Using bits in IPv6 networks for other purposes is orthogonal to those > goals. > > What should we do about it? > Hey, As far as I know, the rule-of-thumb is to allocate /48 per customer. As long as they don't go beyond that, there's nothing to do :) We had a long chat with Peter Lothberg about that during one of the evenings and we calculated that with his addressing and /29 you could number the whole Germany. One provider. I see no need to change the rules, maybe we could mention the /48-per-site-or-per-customer-or-per-end-user-or-whatever-you-want-to-call-it suggestion when writing the assignment plan to get bigger IPv6 space :) Cheers, Jan From Piotr.Strzyzewski at polsl.pl Fri Oct 25 13:22:30 2013 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Fri, 25 Oct 2013 13:22:30 +0200 Subject: [ipv6-wg] 96 more bits... time for some magic after all? In-Reply-To: <20131025123700.07c155ed@earth.home.time-travellers.org> References: <20131025123700.07c155ed@earth.home.time-travellers.org> Message-ID: <20131025112230.GE32019@hydra.ck.polsl.pl> On Fri, Oct 25, 2013 at 12:37:00PM +0200, Shane Kerr wrote: > Using bits in IPv6 networks for other purposes is orthogonal to those > goals. > > What should we do about it? Let's live with that? ;-) Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From tore at fud.no Fri Oct 25 15:13:17 2013 From: tore at fud.no (Tore Anderson) Date: Fri, 25 Oct 2013 15:13:17 +0200 Subject: [ipv6-wg] 96 more bits... time for some magic after all? In-Reply-To: <526A4E3C.4070008@pragma.si> References: <20131025123700.07c155ed@earth.home.time-travellers.org> <526A4E3C.4070008@pragma.si> Message-ID: <526A6E6D.9000109@fud.no> * Jan Zorz > On 10/25/13 12:37 PM, Shane Kerr wrote: >> Using bits in IPv6 networks for other purposes is orthogonal to those >> goals. >> >> What should we do about it? >> > Hey, > > As far as I know, the rule-of-thumb is to allocate /48 per customer. Not really, the policy just says that the minimum assignment size is /64. However, assignments shorter than /48 requires paperwork to be filled in, and since nobody likes paperwork /48 constitutes the de-facto max assignment size in all but exceptional cases. Apart from that it's up to the LIR/ISP to decide how much to assign. In any case we've been cheering on folks who "waste" bits on stuff like 6RD too. Shrug. Personally I'm happy to see folks burn some bits if it results in actual deployments. Tore From jan at pragma.si Fri Oct 25 15:50:28 2013 From: jan at pragma.si (Jan Zorz) Date: Fri, 25 Oct 2013 15:50:28 +0200 Subject: [ipv6-wg] 96 more bits... time for some magic after all? In-Reply-To: <526A6E6D.9000109@fud.no> References: <20131025123700.07c155ed@earth.home.time-travellers.org> <526A4E3C.4070008@pragma.si> <526A6E6D.9000109@fud.no> Message-ID: <526A7724.5030900@pragma.si> On 10/25/13 3:13 PM, Tore Anderson wrote: > In any case we've been cheering on folks who "waste" bits on stuff > like 6RD too. Shrug. Personally I'm happy to see folks burn some bits > if it results in actual deployments. Tore +1 Jan From maximilian.weigmann at iiv.de Fri Oct 25 15:51:09 2013 From: maximilian.weigmann at iiv.de (Weigmann Maximilian) Date: Fri, 25 Oct 2013 15:51:09 +0200 Subject: [ipv6-wg] 96 more bits... time for some magic after all? In-Reply-To: <20131025123700.07c155ed@earth.home.time-travellers.org> References: <20131025123700.07c155ed@earth.home.time-travellers.org> Message-ID: <1382709069.3723.11.camel@wmh43> Hello to All from Bavaria, in my opinion it is very interesting to code additional information using the bits of an Ipv6 address. E.g. you can code geolocation data into the address (in June this year I presented this at the heise German Ipv6 Summit) Imagine a company with many voip-telefone equipment - in this case you could build the ip address with the telefone number. It is possible to build an ip adress with ascii codes and ... I think people will come to many ideas to make Ipv6 addresses more friendly and/or give them more meaning. Greetings from Bavaria Maximilian Weigmann Am Freitag, den 25.10.2013, 12:37 +0200 schrieb Shane Kerr: > All, > > [ gah... hit the wrong key and sent this unfinished ] > > We saw two presentations by network architects at the RIPE meeting that > used bits in their IPv6 addressing plan to carry meaning beyond simple > network topology and packet routing. > > For example, declaring a specific bit in the address to be 1 for voice > traffic or 0 otherwise. > > There are motivations for doing this, which may or may not be valid in > any particular case. There are ways to lessen the amount of addresses > consumed by this (for example by assigning /56 instead of /48 to end > users). > > But I think that the important thing is that we have historically not > considered this sort of use with address allocation policy. In face, > RFC 2050bis was *just* published as RFC 7020: > > http://datatracker.ietf.org/doc/rfc7020/ > > This includes the long-standing historical goals of conservation, > aggregation, and accuracy. > > Using bits in IPv6 networks for other purposes is orthogonal to those > goals. > > What should we do about it? > > Cheers, > > -- > Shane > From maximilian.weigmann at iiv.de Fri Oct 25 16:35:18 2013 From: maximilian.weigmann at iiv.de (Weigmann Maximilian) Date: Fri, 25 Oct 2013 16:35:18 +0200 Subject: [ipv6-wg] 96 more bits... time for some magic after all? In-Reply-To: <20131025123700.07c155ed@earth.home.time-travellers.org> References: <20131025123700.07c155ed@earth.home.time-travellers.org> Message-ID: <1382711718.3723.12.camel@wmh43> Hello to All from Bavaria, in my opinion it is very interesting to code additional information using the bits of an Ipv6 address. E.g. you can code geolocation data into the address (in June this year I presented this at the heise German Ipv6 Summit) Imagine a company with many voip-telefone equipment - in this case you could build the ip address with the telefone number. It is possible to build an ip adress with ascii codes and ... I think people will come to many ideas to make Ipv6 addresses more friendly and/or give them more meaning. Greetings from Bavaria Maximilian Weigmann Am Freitag, den 25.10.2013, 12:37 +0200 schrieb Shane Kerr: > All, > > [ gah... hit the wrong key and sent this unfinished ] > > We saw two presentations by network architects at the RIPE meeting that > used bits in their IPv6 addressing plan to carry meaning beyond simple > network topology and packet routing. > > For example, declaring a specific bit in the address to be 1 for voice > traffic or 0 otherwise. > > There are motivations for doing this, which may or may not be valid in > any particular case. There are ways to lessen the amount of addresses > consumed by this (for example by assigning /56 instead of /48 to end > users). > > But I think that the important thing is that we have historically not > considered this sort of use with address allocation policy. In face, > RFC 2050bis was *just* published as RFC 7020: > > http://datatracker.ietf.org/doc/rfc7020/ > > This includes the long-standing historical goals of conservation, > aggregation, and accuracy. > > Using bits in IPv6 networks for other purposes is orthogonal to those > goals. > > What should we do about it? > > Cheers, > > -- > Shane > From bs at stepladder-it.com Fri Oct 25 17:24:40 2013 From: bs at stepladder-it.com (Benedikt Stockebrand) Date: Fri, 25 Oct 2013 15:24:40 +0000 Subject: [ipv6-wg] 96 more bits... time for some magic after all? In-Reply-To: <20131025123700.07c155ed@earth.home.time-travellers.org> (Shane Kerr's message of "Fri, 25 Oct 2013 12:37:00 +0200") References: <20131025123700.07c155ed@earth.home.time-travellers.org> Message-ID: <87k3h1weyv.fsf@stepladder-it.com> Hi Shane and list, Shane Kerr writes: > All, > > [ gah... hit the wrong key and sent this unfinished ] > > We saw two presentations by network architects at the RIPE meeting that > used bits in their IPv6 addressing plan to carry meaning beyond simple > network topology and packet routing. > [...] > This includes the long-standing historical goals of conservation, > aggregation, and accuracy. > > Using bits in IPv6 networks for other purposes is orthogonal to those > goals. > > What should we do about it? as long as they don't need more than "their share" of the address space as defined by the policy applied to everyone: Nothing. More important however is the question how to deal with them if /when they show up because they have unnecessarily "depleted" their address assignment thanks to encoding stuff in it. I strongly suggest to send them home to renumber their network (and hope it hurts enough to teach them and everyone watching a lesson). It's not much different than with IPv4. Beyond that, there are some more aspects to consider: - Work the numbers. With IPv4 addresses and 32 bits we have kind of managed to come to grips at an intuitive level. With IPv6, this simply doesn't work anymore; a /29 for Deutsche Telekom is ok. However, if they start to code more stuff into the addresses, this will quickly break down. In other words: No matter what, 128 bits are still just 16 bytes. If other people follow suit and start to encode things in their addresses, we may run out of space *very* quickly. - Remember that they effectively nicked the extra five(?) bits from the subnet ID, by handing out /56s instead of /48s as originally intended. They can only do that so often. - I assume you all know about the black/grey market for IPv4 by now. This isn't a technical thing, but a "business model". People will again receive allocations they don't need, and we will see some sort of artificial, money-driven depletion of the IPv6 address space as well. If this gets "successful" before we have to move on from IPv6 for unrelated reasons, or if this will again cause us to run out of addresses before anything else becomes a critical issue, is open for speculation. The only solution to that would have been variable length addresses, and they bring another bunch of problems of their own. Cheers, Benedikt -- Business Grade IPv6 Consulting, Training, Projects Benedikt Stockebrand, Dipl.-Inform. http://www.stepladder-it.com/ From spz at serpens.de Fri Oct 25 17:53:13 2013 From: spz at serpens.de (S.P.Zeidler) Date: Fri, 25 Oct 2013 17:53:13 +0200 Subject: [ipv6-wg] 96 more bits... time for some magic after all? In-Reply-To: <20131025123700.07c155ed@earth.home.time-travellers.org> References: <20131025123700.07c155ed@earth.home.time-travellers.org> Message-ID: <20131025155312.GE19242@serpens.de> Thus wrote Shane Kerr (shane at time-travellers.org): > We saw two presentations by network architects at the RIPE meeting that > used bits in their IPv6 addressing plan to carry meaning beyond simple > network topology and packet routing. > > For example, declaring a specific bit in the address to be 1 for voice > traffic or 0 otherwise. [...] > What should we do about it? As a RIR, nothing. Otherwise: violations of the KISS principle are rarely a good idea. In this case, you might find out that you snuck yourself into a straightjacket a few years down the line. regards, spz -- spz at serpens.de (S.P.Zeidler) From charlie at evilforbeginners.com Fri Oct 25 18:31:16 2013 From: charlie at evilforbeginners.com (Charlie Allom) Date: Fri, 25 Oct 2013 17:31:16 +0100 Subject: [ipv6-wg] 96 more bits... time for some magic after all? In-Reply-To: <20131025123700.07c155ed@earth.home.time-travellers.org> References: <20131025123700.07c155ed@earth.home.time-travellers.org> Message-ID: <20131025163116.GA11110@spodder.com> On Fri, Oct 25, 2013 at 12:37:00PM +0200, Shane Kerr wrote: > > We saw two presentations by network architects at the RIPE meeting that > used bits in their IPv6 addressing plan to carry meaning beyond simple > network topology and packet routing. Hi Shane, for those of us who couldn't follow the RIPE presentations this year, can you link to the slides? I've been wanting to do similar things for storing large media catalogues for years ;) C. -- 0x8486EDA8 http://spodder.com/ From shane at time-travellers.org Fri Oct 25 18:54:43 2013 From: shane at time-travellers.org (Shane Kerr) Date: Fri, 25 Oct 2013 18:54:43 +0200 Subject: [ipv6-wg] 96 more bits... time for some magic after all? In-Reply-To: <20131025163116.GA11110@spodder.com> References: <20131025123700.07c155ed@earth.home.time-travellers.org> <20131025163116.GA11110@spodder.com> Message-ID: <20131025185443.404f1938@earth.home.time-travellers.org> Charlie, On Fri, 25 Oct 2013 17:31:16 +0100 Charlie Allom wrote: > On Fri, Oct 25, 2013 at 12:37:00PM +0200, Shane Kerr > wrote: > > > > We saw two presentations by network architects at the RIPE meeting > > that used bits in their IPv6 addressing plan to carry meaning > > beyond simple network topology and packet routing. > > Hi Shane, for those of us who couldn't follow the RIPE presentations > this year, can you link to the slides? Sure, here they are: https://ripe67.ripe.net/presentations/251-ripe2-4.pdf https://ripe67.ripe.net/presentations/222-ripe67-yanodd-ipv6-addressing.pdf Cheers, -- Shane From tjc at ecs.soton.ac.uk Sat Oct 26 09:22:27 2013 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Sat, 26 Oct 2013 08:22:27 +0100 Subject: [ipv6-wg] 96 more bits... time for some magic after all? In-Reply-To: <20131025123515.1b768c21@earth.home.time-travellers.org> References: <20131025123515.1b768c21@earth.home.time-travellers.org> <7C80783A-5580-46BE-B676-A35B2D14233B@ecs.soton.ac.uk> Message-ID: Hi, On 25 Oct 2013, at 11:35, Shane Kerr wrote: > All, > > We saw two presentations by network architects at the RIPE meeting that > used bits in their IPv6 addressing plan to carry meaning beyond simple > network topology and packet routing. > > For example, declaring a specific bit in the address to be 1 for voice > traffic or 0 otherwise. > > There are motivations for doing this, which may or may not be valid in > any particular case. There are ways to lessen the amount of addresses > consumed by this (for example by assigning /56 instead of /48 to end > users). > > But I think that the important thing is that we have historically not > considered this sort of use with address allocation policy. In face, > RFC 2050bis was *just* published as RFC 7050: Seems ike more of http://tools.ietf.org/html/draft-jiang-semantic-prefix-06 Which has drawn mixed reaction at the IETF. Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From rogerj at gmail.com Sat Oct 26 10:56:18 2013 From: rogerj at gmail.com (=?ISO-8859-1?Q?Roger_J=F8rgensen?=) Date: Sat, 26 Oct 2013 10:56:18 +0200 Subject: [ipv6-wg] 96 more bits... time for some magic after all? In-Reply-To: <87k3h1weyv.fsf@stepladder-it.com> References: <20131025123700.07c155ed@earth.home.time-travellers.org> <87k3h1weyv.fsf@stepladder-it.com> Message-ID: On Fri, Oct 25, 2013 at 5:24 PM, Benedikt Stockebrand wrote: > Hi Shane and list, > > Shane Kerr writes: > >> All, >> >> [ gah... hit the wrong key and sent this unfinished ] >> >> We saw two presentations by network architects at the RIPE meeting that >> used bits in their IPv6 addressing plan to carry meaning beyond simple >> network topology and packet routing. >> [...] >> This includes the long-standing historical goals of conservation, >> aggregation, and accuracy. >> >> Using bits in IPv6 networks for other purposes is orthogonal to those >> goals. >> >> What should we do about it? > > as long as they don't need more than "their share" of the address space > as defined by the policy applied to everyone: Nothing. > > More important however is the question how to deal with them if /when > they show up because they have unnecessarily "depleted" their address > assignment thanks to encoding stuff in it. I strongly suggest to send > them home to renumber their network (and hope it hurts enough to teach > them and everyone watching a lesson). > > It's not much different than with IPv4. It is just bits, numbers, never forget that. How people/ISP/something chose to use what is available to them really is upto them. We have some experience since we started to use IPv6 back in the 90s, and we also have some guidelines on what is a good idea, and what is a really horrible idea. What is a bad idea, so far almost all agree somehow, is to put too much semantic into the IPv6 address. Some is great, and usefull, but chose wisely. Only difference from IPv4 is the amount of space you can _misuse_. It's upto each and every operator do make the chose _they_ think is the right for themself. If they ignore the advices given and run out, renumber. If they run out due to size and growth, and they haven't wasted space, used their available /29 wisely by every advice given...give them another prefix. > Beyond that, there are some more aspects to consider: > > - Work the numbers. With IPv4 addresses and 32 bits we have kind of > managed to come to grips at an intuitive level. With IPv6, this > simply doesn't work anymore; a /29 for Deutsche Telekom is > ok. However, if they start to code more stuff into the addresses, this > will quickly break down. In other words: No matter what, 128 bits are > still just 16 bytes. If other people follow suit and start to encode > things in their addresses, we may run out of space *very* quickly. I did some calculation long time ago, 2002-2003 or around there, only thing I remember is that IPv6 isn't really that huge, it's big and plenty for sure but if we start to waste we will run out quite fast. Very fast. One way to waste is to give every single customer a /48 when you are really really big. /56 work just fine really, even for techies like me :) However IPv6 is big enough that most people will not feel any pain with it, some however will start to get into trouble in 5-10years time, guess more like around in 7 years. The reason? They made a too static model on how they wanted to use their available space. But you have to be big to get into that trouble. > - Remember that they effectively nicked the extra five(?) bits from the > subnet ID, by handing out /56s instead of /48s as originally > intended. They can only do that so often. There was major discussion just to get that /56 into the documents. Upto that point there was /64 pr.LAN, /48 for the rest. Now we're relaxing it even more. Are discussion on moving away from /64's on the wire to... Doesn't this sound like A/B/C-class network vs CIDR? >From my own experience over the years, since early days in 97 upto now, there isn't a one size fits all as I too believed in the early days of IPv6. * For one server running in the cloud I got a /112, that work just fine really. * Somewhere else I'm using a /50 on the wire, that also work just fine. * I have tried to use an entire /48 but failed. I tried to build my own network with VPN, routings and everything across the different servers and routers I have spread around. That /48 was big enough for me:) * I tried to build a big routed, multisite network using a /56, that also worked upto a certain size :) -- Roger Jorgensen | ROJO9-RIPE rogerj at gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no From dez at otenet.gr Sat Oct 26 14:52:34 2013 From: dez at otenet.gr (Yannis Nikolopoulos) Date: Sat, 26 Oct 2013 15:52:34 +0300 Subject: [ipv6-wg] 96 more bits... time for some magic after all? In-Reply-To: <20131025155312.GE19242@serpens.de> References: <20131025123700.07c155ed@earth.home.time-travellers.org> <20131025155312.GE19242@serpens.de> Message-ID: <526BBB12.1090705@otenet.gr> Hello, On 10/25/2013 06:53 PM, S.P.Zeidler wrote: > Thus wrote Shane Kerr (shane at time-travellers.org): > >> We saw two presentations by network architects at the RIPE meeting that >> used bits in their IPv6 addressing plan to carry meaning beyond simple >> network topology and packet routing. >> >> For example, declaring a specific bit in the address to be 1 for voice >> traffic or 0 otherwise. > [...] > >> What should we do about it? > As a RIR, nothing. what about as one of RIPE's WGs? Should we go on and produce a BCP document of some kind? As the author of this addressing plan (https://ripe67.ripe.net/presentations/222-ripe67-yanodd-ipv6-addressing.pdf) , my main motivation for presenting it was to show that it is possible to encode basic information in an addressing plan (without wasting too much space) and still keep it simple . For example, even IPv4 addressing plans were location-aware, that's nothing new. Well, its even easier and more effective in IPv6 addressing, because of the number of bits available. As far as encoding service type, no space is wasted because it is encoded after the /56 boundary ;) , even making it possible for QOS. As I mentioned in the presentation, this is our 3rd or 4th try over the past ~10 years. So far, with the help of some basic heuristics, it seems to be working out fine cheers, Yannis > > Otherwise: violations of the KISS principle are rarely a good idea. > In this case, you might find out that you snuck yourself into a > straightjacket a few years down the line. > > regards, > spz From bs at stepladder-it.com Sun Oct 27 08:54:42 2013 From: bs at stepladder-it.com (Benedikt Stockebrand) Date: Sun, 27 Oct 2013 07:54:42 +0000 Subject: [ipv6-wg] 96 more bits... time for some magic after all? In-Reply-To: ("Roger \=\?utf-8\?Q\?J\=C3\=B8rgensen\=22's\?\= message of "Sat, 26 Oct 2013 10:56:18 +0200") References: <20131025123700.07c155ed@earth.home.time-travellers.org> <87k3h1weyv.fsf@stepladder-it.com> Message-ID: <87ob6bkv25.fsf@stepladder-it.com> Hi Roger and list, On Fri, Roger J?rgensen writes: > Oct 25, 2013 at 5:24 PM, Benedikt Stockebrand > wrote: >> [...] >> More important however is the question how to deal with them if /when >> they show up because they have unnecessarily "depleted" their address >> assignment thanks to encoding stuff in it. >> [...] > If they run out due to size and growth, and they haven't wasted space, > used their available /29 wisely by every advice given...give them > another prefix. That's what I meant by "unnecessarily 'depleted'". If they actually grow beyond their /29 or whatever, let them have another prefix. What I wouldn't want to see however is that some big player gets some extra address space because they wasted their existing one. Once that happens, everyone will demand the same. And yes, I've had these discussions. In particular, the idea to bit-encode the services (i.e. significant port numbers) somewhere in the subnet prefix. Eventually these people decided "well, we have a /12 for IPv4, so it's only fair we also get a /12 for IPv6". At that point I pretty much gave up and told them to request that from their RIR... > One way to waste is to give every single customer a /48 when you are > really really big. /56 work just fine really, even for techies like me :) Sorry, but I disagree on that. A /56 is fine for today's requirements, but if this hype about the "Internet of Things" really takes off and you want to put things into different subnets, a /56 may occasionally be a problem even for consumer households. Not today, but think anything from ten to fourty years. > However IPv6 is big enough that most people will not feel any pain with > it, some however will start to get into trouble in 5-10years time, guess > more like around in 7 years. The reason? They made a too static model > on how they wanted to use their available space. Agreed, but... > But you have to be big to get into that trouble. I don't see any reason why size has to do with it. The problem is more of a ratio between size and allocated address space---and the technical knowledge around. (And no, unlike somebody else on this list I don't believe it feasible for a consumer to call in a CCIE every time they need some networked deviced hooked up.) > There was major discussion just to get that /56 into the documents. > Upto that point there was /64 pr.LAN, /48 for the rest. Now we're relaxing > it even more. Are discussion on moving away from /64's on the wire to... If /64 is given up, all sorts of shit will happen. It has been part of the specs for long enough that a number of implementations will rely on it. It's not just autoconfiguration, but when it comes to embedded system/microcontroller implementations, changing that is rather difficult. Additionally, anything that can be (mis-)configured exponentially adds (or rather, multiplies) to the frustration potential for end users. > Doesn't this sound like A/B/C-class network vs CIDR? You mean VLSM, I assume? > * For one server running in the cloud I got a /112, that work just fine really. ...until you do an upgrade on the server that relies on RFC 4291. > * Somewhere else I'm using a /50 on the wire, that also work just fine. Same issue. Yes, at least some implementations support that right now, but you shouldn't rely on that. Additionally, for whoever may have to run that system further later on you set up some ugly surprise that way. > * I have tried to use an entire /48 but failed. I tried to build my > own network with VPN, routings and everything across the different > servers and routers I have spread around. That /48 was big enough for > me:) Oha. So you have too many machines to fit into a /64 in a single subnet? > * I tried to build a big routed, multisite network using a /56, that > also worked upto a certain size :) Sorry, I don't get what you want to say there. Cheers, Benedikt -- Business Grade IPv6 Consulting, Training, Projects Benedikt Stockebrand, Dipl.-Inform. http://www.stepladder-it.com/ From dez at otenet.gr Sun Oct 27 11:02:46 2013 From: dez at otenet.gr (Yannis Nikolopoulos) Date: Sun, 27 Oct 2013 12:02:46 +0200 Subject: [ipv6-wg] 96 more bits... time for some magic after all? In-Reply-To: <87ob6bkv25.fsf@stepladder-it.com> References: <20131025123700.07c155ed@earth.home.time-travellers.org> <87k3h1weyv.fsf@stepladder-it.com> <87ob6bkv25.fsf@stepladder-it.com> Message-ID: <526CE4C6.9060003@otenet.gr> On 10/27/2013 09:54 AM, Benedikt Stockebrand wrote: > Hi Roger and list, > > On Fri, Roger J?rgensen writes: > >> Oct 25, 2013 at 5:24 PM, Benedikt Stockebrand >> wrote: >> What I wouldn't want to see however is that some big player gets some >> extra address space because they wasted their existing one. Once that >> happens, everyone will demand the same. that's the second time I read this in this thread. Why would this happen? All allocations are subject to RIR policy >> One way to waste is to give every single customer a /48 when you are >> really really big. /56 work just fine really, even for techies like me :) > Sorry, but I disagree on that. A /56 is fine for today's requirements, > but if this hype about the "Internet of Things" really takes off and you > want to put things into different subnets, a /56 may occasionally be a > problem even for consumer households. Not today, but think anything > from ten to fourty years. 40 years from now? Many, more significant changes will probably overshadow this. Otherwise, 256 different policies in a home sound just fine > >> There was major discussion just to get that /56 into the documents. >> Upto that point there was /64 pr.LAN, /48 for the rest. Now we're relaxing >> it even more. Are discussion on moving away from /64's on the wire to... > It's not just autoconfiguration, but when it comes to embedded > system/microcontroller implementations, changing that is rather > difficult. care to elaborate on that? >> * For one server running in the cloud I got a /112, that work just fine really. > ...until you do an upgrade on the server that relies on RFC 4291. > >> * Somewhere else I'm using a /50 on the wire, that also work just fine. > Same issue. Yes, at least some implementations support that right now, > but you shouldn't rely on that. Additionally, for whoever may have to > run that system further later on you set up some ugly surprise that way. again, care to elaborate a bit? How's a /50 not compliant with RFC 4291? > Cheers, Benedikt cheers, Yannis From spz at serpens.de Sun Oct 27 12:15:32 2013 From: spz at serpens.de (S.P.Zeidler) Date: Sun, 27 Oct 2013 12:15:32 +0100 Subject: [ipv6-wg] 96 more bits... time for some magic after all? In-Reply-To: <526BBB12.1090705@otenet.gr> References: <20131025123700.07c155ed@earth.home.time-travellers.org> <20131025155312.GE19242@serpens.de> <526BBB12.1090705@otenet.gr> Message-ID: <20131027111531.GD1175@serpens.de> Thus wrote Yannis Nikolopoulos (dez at otenet.gr): > >>For example, declaring a specific bit in the address to be 1 for voice > >>traffic or 0 otherwise. > >[...] > > > >>What should we do about it? > >As a RIR, nothing. > > what about as one of RIPE's WGs? The addressing plan within an allocation is the LIRs responsibility, and if they want to shoot themselves in the foot they may do so. Maybe their network designer is a genius or they have a special environment, and the complicated plan they come up with turns out to be gold. In general, "as simple as you can get away with" is a good aim, though. It won't only need to look good on paper, it'll need to be useable and maintainable, too. > Should we go on and produce a BCP > document of some kind? As the author of this addressing plan > > (https://ripe67.ripe.net/presentations/222-ripe67-yanodd-ipv6-addressing.pdf) , my main motivation for presenting it was to show that it is possible to encode basic information in an addressing plan (without wasting too much space) and still keep it simple . For example, even IPv4 addressing plans were location-aware, that's nothing new. Well, its even easier and more effective in IPv6 addressing, because of the number of bits available. As far as encoding service type, no space is wasted because it is encoded after the /56 boundary ;) , even making it possible for QOS. Ok, let me be less terse. I'm not speaking from a scientific research position but from a gut reaction which is based on some practical experience. I think if you want to encode something in the netmask area, you want to define ranges, not bits, you want to prioritize routing (i.e., obviously "location") and keep "magic info" to the really really basic, like "the '0' subnet is the PoP LAN'", because if the people in the NOC need to do a drawing of the bits or use a calculator before they can assign the proper address to a router that'll not be a happy network (use of tools alleviates that, but the more complicated your rules the more prone to bugs they will be). Humans can learn the most amazing feats of pattern matching, given enough time, but you want to give the new hire who has only been around for 6 months a chance to also immediately *see* that the address given is wrong in that use context if your routers discriminate on them. If your network equipment does not use the encoded information, thus making errors obvious by causing failures, you can expect that the information encoded is a cute note but not a reliable one. There's nothing wrong with conventions, especially if they are entertaining, as long as you remember that that's all they are, and that they can be put out with the garbage if there is a good reason. For a network plan I have been involved in, for an ISP with many locations and expecting growth, we basically said: We have small, medium, large and huge locations. We will section up the entire available space in equal chunks. (this gives a minimum standard network size in the routing table; customers will cause this to be messed up :) Each location will get a chunk and when they use it up, another one. We will try to keep the chunks going to a location contiguous, but no guarantees. To be able to add contiguous chunks, we will leave gaps between initial assignments, and the size of the location determines the size of its gap; initially, group net-near locations next to each other but also make no promises. Lowest /64 of the initial assignment is location core LAN, rest of the lowest /48 are further LANs or transfer addresses: convention, no guarantees. Should the /48 run out, just take the next free one. This is fairly simple and hopefully also maintainable. Additional knowledge about a network may lead to different results; but it's easy to underestimate growth, or to misjudge where growth will happen, and when that happens it shouldn't cause too much pain - especially not sustained pain. Regarding the addressing plan you made: I don't know your network, you do. My comments may thus simply not apply because of local conditions. So, adding this packet of salt: Not to be snide, but "trusted" is a bad designation :) You know all the jokes about the evil bit? Being able to immediately see that a fault is probably your issue is good, trusting large ranges of address space less so. Traffic types in front of location prevents aggregation, which is not a huge issue these days, but still unnessecarily inefficient. That's also what I don't like about your loopback choice and transfer addresses choice; your routing table will contain quite a bunch of /128. Also, having both traffic type and service seems redundant (is there an issue for network ops to get prefixes configured in a local firewall? Otherwise I'd expect infrastructure to just be treated as another service), and lower than /56 you normally leave to your customers (a case of "local specialties not mentioned" that make you contol those bits as well?) No quarrel with encoding the vlan id in the local infrastructure subnet as long as you agree beforehand to write numbers (hex) or strings; that's an example of convention. If you write string, the presence of a letter can mean it's not a vlan. Your plan of numbering residential customers up and business customers down will not survive contact with the enemy^Wcustomer unscathed; also its information content is limited as long as you don't know where the border is (and that will be different in every location, unless you are willing to accept large gaps that may not fill), but as a convention, why not. I'm missing an explicit plan on how locations get grown. You assume you'll never run out with a /40? regards, spz -- spz at serpens.de (S.P.Zeidler) From rogerj at gmail.com Sun Oct 27 16:12:14 2013 From: rogerj at gmail.com (=?ISO-8859-1?Q?Roger_J=F8rgensen?=) Date: Sun, 27 Oct 2013 16:12:14 +0100 Subject: [ipv6-wg] 96 more bits... time for some magic after all? In-Reply-To: <87ob6bkv25.fsf@stepladder-it.com> References: <20131025123700.07c155ed@earth.home.time-travellers.org> <87k3h1weyv.fsf@stepladder-it.com> <87ob6bkv25.fsf@stepladder-it.com> Message-ID: On Sun, Oct 27, 2013 at 8:54 AM, Benedikt Stockebrand wrote: > Hi Roger and list, > > On Fri, Roger J?rgensen writes: >> One way to waste is to give every single customer a /48 when you are >> really really big. /56 work just fine really, even for techies like me :) > > Sorry, but I disagree on that. A /56 is fine for today's requirements, > but if this hype about the "Internet of Things" really takes off and you > want to put things into different subnets, a /56 may occasionally be a > problem even for consumer households. Not today, but think anything > from ten to fourty years. We'll have bigger problems, and other problems in 10years time. We have probably start to use more than the 2000::/3 space for one thing. That might change the game? I do think /56 is fine for most thing, really for most thing. But if someone want to use /48 just to be sure. Fine let them do that. If a user want a /48 instead of /56, then the operators actually _should_ hand it out. >> But you have to be big to get into that trouble. > > I don't see any reason why size has to do with it. The problem is more > of a ratio between size and allocated address space---and the technical > knowledge around. (And no, unlike somebody else on this list I don't > believe it feasible for a consumer to call in a CCIE every time they > need some networked deviced hooked up.) are work ongoing elsewhere that maybe can fix that connect-anything-anyway-you-like problem we've always had. But that's not a policy question. >> There was major discussion just to get that /56 into the documents. >> Upto that point there was /64 pr.LAN, /48 for the rest. Now we're relaxing >> it even more. Are discussion on moving away from /64's on the wire to... > > If /64 is given up, all sorts of shit will happen. It has been part of > the specs for long enough that a number of implementations will rely on > it. It's not just autoconfiguration, but when it comes to embedded > system/microcontroller implementations, changing that is rather > difficult. > > Additionally, anything that can be (mis-)configured exponentially adds > (or rather, multiplies) to the frustration potential for end users. agree, this /64 is one of the really really good thing. It can be considered a waste of address space but it's a nice division between net-prefix and LAN-prefix :-) >> * For one server running in the cloud I got a /112, that work just fine really. > > ...until you do an upgrade on the server that relies on RFC 4291. so what? I buy a service, and if the provider support me installing something that break their setup, then it's really their problem. Pain is mine but problem is theirs to fix. >> * Somewhere else I'm using a /50 on the wire, that also work just fine. > > Same issue. Yes, at least some implementations support that right now, > but you shouldn't rely on that. Additionally, for whoever may have to > run that system further later on you set up some ugly surprise that way. again, so what? I've done worse use of the IPv6 space over the years and _only_ thing that bit me really hard was the /127 problem ages ago. But we got around that to, and it bit me because I did things I wasn't supposed todo:) Again - operators choice of operating their own network. >> * I have tried to use an entire /48 but failed. I tried to build my >> own network with VPN, routings and everything across the different >> servers and routers I have spread around. That /48 was big enough for >> me:) > > Oha. So you have too many machines to fit into a /64 in a single > subnet? No, I had enough of /64 in a /48. I tried to run out of /64's but hadn't enough sites or enough machines. I really tried, even used /52, /56 etc to :-) The operating headache took me way before the address space was empty. Could gone further with automaton but that wasn't the point. >> * I tried to build a big routed, multisite network using a /56, that >> also worked upto a certain size :) > > Sorry, I don't get what you want to say there. a /56 is plenty for most cases. However I was able to run out of available /64 to use before the operating headache took me :-) I think that if an end-user ask for a /48 then the operators _should_ provide you with a /48. -- Roger Jorgensen | ROJO9-RIPE rogerj at gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no From bs at stepladder-it.com Sun Oct 27 19:20:10 2013 From: bs at stepladder-it.com (Benedikt Stockebrand) Date: Sun, 27 Oct 2013 18:20:10 +0000 Subject: [ipv6-wg] 96 more bits... time for some magic after all? References: <20131025123700.07c155ed@earth.home.time-travellers.org> <87k3h1weyv.fsf@stepladder-it.com> <87ob6bkv25.fsf@stepladder-it.com> <526CE4C6.9060003@otenet.gr> Message-ID: <87ob6ainj9.fsf@stepladder-it.com> Hi Yannis and list, Yannis Nikolopoulos writes: > On 10/27/2013 09:54 AM, Benedikt Stockebrand wrote: >> Hi Roger and list, >> >> On Fri, Roger J?rgensen writes: >> >>> Oct 25, 2013 at 5:24 PM, Benedikt Stockebrand >>> wrote: >>> What I wouldn't want to see however is that some big player gets >>> some extra address space because they wasted their existing >>> one. Once that happens, everyone will demand the same. > > that's the second time I read this in this thread. Why would this > happen? All allocations are subject to RIR policy yes, but policies can be circumvented, lobbied out of the way or overridden by legislation, as was effectively the case with the Nortel/Microsoft deal, among others. There used to be a policy that IP addresses can't be traded. Take a look at the recordings from the RIPE meeting last week to see what happens right now. >>> One way to waste is to give every single customer a /48 when you are >>> really really big. /56 work just fine really, even for techies like me :) >> Sorry, but I disagree on that. A /56 is fine for today's requirements, >> but if this hype about the "Internet of Things" really takes off and you >> want to put things into different subnets, a /56 may occasionally be a >> problem even for consumer households. Not today, but think anything >> from ten to fourty years. > > 40 years from now? Many, more significant changes will probably > overshadow this. Otherwise, 256 different policies in a home sound > just fine According to Bob Kahn with exactly the same reasoning the original 6 bit addresses in the Arpanet were widely ridiculed; pretty much the same happened again again when they went straight for 32 bit addresses in IPv4 (which was pretty much exactly the 40 years I mentioned ago, so that's where I got that number from). If you plan for future networks by today's demands, without taking into account either some future growth nor some imminent or at least apparent developments, like the currrent growth of networked embedded systems, you won't make it through even the next ten years. And considering the time it took for IPv6 to take off, even if we started on developing its successor today, we'd have to live with IPv6 for another 25 years or more; IPv4 will likely last another five years, making it a total lifetime of 45 years. We might as well accept that whatever we do today will haunt us at that long as well. >>> There was major discussion just to get that /56 into the documents. >>> Upto that point there was /64 pr.LAN, /48 for the rest. Now we're relaxing >>> it even more. Are discussion on moving away from /64's on the wire to... >> It's not just autoconfiguration, but when it comes to embedded >> system/microcontroller implementations, changing that is rather >> difficult. > > care to elaborate on that? Yes, but I'd rather do that in a separate thread/with a new subject... >>> * Somewhere else I'm using a /50 on the wire, that also work just fine. >> Same issue. Yes, at least some implementations support that right now, >> but you shouldn't rely on that. Additionally, for whoever may have to >> run that system further later on you set up some ugly surprise that way. > > again, care to elaborate a bit? Yes. If somebody decides to remove support for a configurable subnet prefix length, based on the fact that the RFCs mentioned below don't allow anything but a /64 as subnet prefix, an upgrade of a system with a differently configured subnet prefix will blow up in your face. If this happens because of a security hole, this leaves you the choice of either running the vulnerable old version, or taking a (production) system down until you've sorted out your network setup. There are at least two valid reasons to remove support for a configurable subnet prefix length: It adds overhead to the implementation (again, this is particularly troublesome with microcontrollers) and it is yet another option to frustrate end users. As far as your possible successors as sysadmin/netadmin are concerned: If somebody in some not-so-far-away future inherits the systems you have set up and has to handle them, doing something that is not covered by specifications but happens to work with some implementations, this is quite likely to blow up in their faces---and your (former) company's, since this is likely to cost noticeable money. Yes, I've been down that road in several slightly different contexts, and thinking of the trouble it caused I consider these sorts of time bombs reason enough to sack whoever set them up. And no, sorry, I can't provide any more details, except maybe that with BIND4 it was possible to put periods in DNS labels... As far as end users are concerned: When it comes to systems that are operated by end users who don't understand---and shouldn't need to understand---the internals of the stuff they use, every single configuration options is something that at best adds, or rather multiplies, to the number of options they have to try to get things up and running. This is bad for the end user as well as the vendor of the gear, so minimizing the number of configurables is actually one of the key measures to keep non-professional end users happy. > How's a /50 not compliant with RFC 4291? (One of these days I'll actually make that into a separate three-page RFC, so people who won't or can't read 4291 can be referred to that...) RFC 4291, page 8, section 2.5.1, for all unicast addresses except those starting with 000b, which is currently :: and ::1, and again in RFC 4291, page 10, section 2.5.4 (for global unicast addresses) RFC 4291, page 11, section 2.5.6 (for link-local unicast addresses) RFC 4193, page 3, section 3.1 (for unique-local unicast addresses) Cheers, Benedikt -- Business Grade IPv6 Consulting, Training, Projects Benedikt Stockebrand, Dipl.-Inform. http://www.stepladder-it.com/ From dez at otenet.gr Sun Oct 27 20:27:36 2013 From: dez at otenet.gr (Yannis Nikolopoulos) Date: Sun, 27 Oct 2013 21:27:36 +0200 Subject: [ipv6-wg] 96 more bits... time for some magic after all? In-Reply-To: <87ob6ainj9.fsf@stepladder-it.com> References: <20131025123700.07c155ed@earth.home.time-travellers.org> <87k3h1weyv.fsf@stepladder-it.com> <87ob6bkv25.fsf@stepladder-it.com> <526CE4C6.9060003@otenet.gr> <87ob6ainj9.fsf@stepladder-it.com> Message-ID: <526D6928.1040703@otenet.gr> Hello, On 10/27/2013 08:20 PM, Benedikt Stockebrand wrote: > Hi Yannis and list, > > Yannis Nikolopoulos writes: > >> On 10/27/2013 09:54 AM, Benedikt Stockebrand wrote: >>> Hi Roger and list, >>> >>> On Fri, Roger J?rgensen writes: >>> >>>> Oct 25, 2013 at 5:24 PM, Benedikt Stockebrand >>>> wrote: >>>> What I wouldn't want to see however is that some big player gets >>>> some extra address space because they wasted their existing >>>> one. Once that happens, everyone will demand the same. >> that's the second time I read this in this thread. Why would this >> happen? All allocations are subject to RIR policy > yes, but policies can be circumvented, lobbied out of the way or > overridden by legislation, as was effectively the case with the > Nortel/Microsoft deal, among others. usually, policy works just fine and by policy I mean something like RIPE-589 which aims to make sure that folks don't just waste their precious space as per your original comment. Nortel/MS case is totally different IMO. > There used to be a policy that IP addresses can't be traded. Take a > look at the recordings from the RIPE meeting last week to see what > happens right now. It's still up to us (RIR members) to change the shape of things to come, although I feel we're off-topic again :) >>>> One way to waste is to give every single customer a /48 when you are >>>> really really big. /56 work just fine really, even for techies like me :) >>> Sorry, but I disagree on that. A /56 is fine for today's requirements, >>> but if this hype about the "Internet of Things" really takes off and you >>> want to put things into different subnets, a /56 may occasionally be a >>> problem even for consumer households. Not today, but think anything >>> from ten to fourty years. >> 40 years from now? Many, more significant changes will probably >> overshadow this. Otherwise, 256 different policies in a home sound >> just fine > According to Bob Kahn with exactly the same reasoning the original 6 bit > addresses in the Arpanet were widely ridiculed; pretty much the same > happened again again when they went straight for 32 bit addresses in > IPv4 (which was pretty much exactly the 40 years I mentioned ago, so > that's where I got that number from). > > If you plan for future networks by today's demands, without taking into > account either some future growth nor some imminent or at least apparent > developments, like the currrent growth of networked embedded systems, > you won't make it through even the next ten years. > > And considering the time it took for IPv6 to take off, even if we > started on developing its successor today, we'd have to live with IPv6 > for another 25 years or more; IPv4 will likely last another five years, > making it a total lifetime of 45 years. We might as well accept that > whatever we do today will haunt us at that long as well. I was merely stating that 40 years from now is an awfully long time to plan for (as far as an addressing plan goes) and to be honest I don't know many people who do. > >>>> * Somewhere else I'm using a /50 on the wire, that also work just fine. >>> Same issue. Yes, at least some implementations support that right now, >>> but you shouldn't rely on that. Additionally, for whoever may have to >>> run that system further later on you set up some ugly surprise that way. >> again, care to elaborate a bit? > [snip] > >> How's a /50 not compliant with RFC 4291? actually, I missed "on the wire" from the original comment :) cheers, Yannis > > > > Cheers, > > Benedikt > From dez at otenet.gr Sun Oct 27 20:50:44 2013 From: dez at otenet.gr (Yannis Nikolopoulos) Date: Sun, 27 Oct 2013 21:50:44 +0200 Subject: [ipv6-wg] 96 more bits... time for some magic after all? In-Reply-To: <20131027111531.GD1175@serpens.de> References: <20131025123700.07c155ed@earth.home.time-travellers.org> <20131025155312.GE19242@serpens.de> <526BBB12.1090705@otenet.gr> <20131027111531.GD1175@serpens.de> Message-ID: <526D6E94.6090901@otenet.gr> Hello, first of all thanks a lot for the feedback. On 10/27/2013 01:15 PM, S.P.Zeidler wrote: > Thus wrote Yannis Nikolopoulos (dez at otenet.gr): > > [snip] >> Should we go on and produce a BCP >> document of some kind? As the author of this addressing plan >> >> (https://ripe67.ripe.net/presentations/222-ripe67-yanodd-ipv6-addressing.pdf) , my main motivation for presenting it was to show that it is possible to encode basic information in an addressing plan (without wasting too much space) and still keep it simple . For example, even IPv4 addressing plans were location-aware, that's nothing new. Well, its even easier and more effective in IPv6 addressing, because of the number of bits available. As far as encoding service type, no space is wasted because it is encoded after the /56 boundary ;) , even making it possible for QOS. > Ok, let me be less terse. I'm not speaking from a scientific research > position but from a gut reaction which is based on some practical > experience. > > [...] > If your network equipment does not use the encoded information, > thus making errors obvious by causing failures, you can expect that > the information encoded is a cute note but not a reliable one. > There's nothing wrong with conventions, especially if they are > entertaining, as long as you remember that that's all they are, and that > they can be put out with the garbage if there is a good reason. i agree, it's happened way too many times in the past... > For a network plan I have been involved in, for an ISP with many > locations and expecting growth, we basically said: > > We have small, medium, large and huge locations. we've been down that road a few times (with both v4 and v6) but decided against it in the current plan. > [...] > Regarding the addressing plan you made: I don't know your network, you do. > My comments may thus simply not apply because of local conditions. > So, adding this packet of salt: > > Not to be snide, but "trusted" is a bad designation :) You know all the > jokes about the evil bit? Being able to immediately see that a fault > is probably your issue is good, trusting large ranges of address space > less so. yep, I agree. We're not exactly using "trusted vs non-trusted", more like "infrastructure vs customers". Infrastructure is not all trusted of course ;) > Traffic types in front of location prevents aggregation, which is not a > huge issue these days, but still unnessecarily inefficient. Actually, we're aiming at being efficient by aggregating customer prefixes which are smaller than /32 > That's also what I don't like about your loopback choice and transfer > addresses choice; your routing table will contain quite a bunch of /128. > > Also, having both traffic type and service seems redundant (is there an > issue for network ops to get prefixes configured in a local firewall? > Otherwise I'd expect infrastructure to just be treated as another > service), and lower than /56 you normally leave to your customers > (a case of "local specialties not mentioned" that make you contol > those bits as well?) infrastructure being another service was considered and may actually be a better idea :) . About messing with bits 56-64 for customer services, I realise it sounds awkward but what we *might* do in the near future (when and if it makes sense) is to apply certain policies for certain groups of /64s and that's that. > > No quarrel with encoding the vlan id in the local infrastructure subnet > as long as you agree beforehand to write numbers (hex) or strings; > that's an example of convention. If you write string, the presence > of a letter can mean it's not a vlan. > > Your plan of numbering residential customers up and business customers > down will not survive contact with the enemy^Wcustomer unscathed; also > its information content is limited as long as you don't know where the > border is (and that will be different in every location, unless you are > willing to accept large gaps that may not fill), but as a convention, why > not. I'm not sure I follow here :) > I'm missing an explicit plan on how locations get grown. You assume you'll > never run out with a /40? on the contrary, we're expecting to run out. If that's the case, either a 2nd /40 (location) is allocated for the same PoP (e.g athens1, athens2) or the same location is used in the next "customer" /32 cheers, Yannis > > regards, > spz From bs at stepladder-it.com Sun Oct 27 21:06:32 2013 From: bs at stepladder-it.com (Benedikt Stockebrand) Date: Sun, 27 Oct 2013 20:06:32 +0000 Subject: [ipv6-wg] IPv6 and embedded systems was: Re: 96 more bits... time for some magic after all? In-Reply-To: <87ob6ainj9.fsf@stepladder-it.com> (Benedikt Stockebrand's message of "Sun, 27 Oct 2013 18:20:10 +0000") References: <20131025123700.07c155ed@earth.home.time-travellers.org> <87k3h1weyv.fsf@stepladder-it.com> <87ob6bkv25.fsf@stepladder-it.com> <526CE4C6.9060003@otenet.gr> <87ob6ainj9.fsf@stepladder-it.com> Message-ID: <87iowiiilz.fsf_-_@stepladder-it.com> As threatened... Benedikt Stockebrand writes: > Hi Yannis and list, > > Yannis Nikolopoulos writes: >>>> Are discussion on moving away from /64's on the wire to... >>> It's not just autoconfiguration, but when it comes to embedded >>> system/microcontroller implementations, changing that is rather >>> difficult. >> >> care to elaborate on that? > > Yes, but I'd rather do that in a separate thread/with a new subject... Ok, sorry but this will be longish. I'll try to organize things a bit. Design considerations --------------------- Embedded systems are generally designed and built for a fixed purpose. (Arduino et al are development/prototyping platforms not really fit for production use.) When building for production it is essential to pick the smallest, most limited microcontroller or CPU that can do the job and only put things in there that are known to be needed. In the networking world you'd follow a similar approach when building a custom firewall setup, in case you've ever tried to do so. There are several reasons why it is so important to put effort into this minimization when building embedded systems. First of all, it reduces cost. And in a market where a few cents in price make the difference if your product or your competitors makes it to the shelves of the major electronics outlets, this is absolutely critical. If you sell your SIP phone for example at 15.30 Euro/USD/whatever and your competitor sells at 15.20, then you are out of business; if you manage to reduce your price by .15, then you survive. It's as simple as that. Next, whatever isn't there can't break; this is particularly important because many embedded systems simply *must* work, no matter what. If your car's anti-skid system crashes at the wrong moment, so will you. In Germany a few years ago, some ISPs touted DSL, promising "availability of up to 99%". Aside from the obvious logical nonsense in here, even if they had promised a 99% availability, that's several orders of magnitude too bad for many embedded systems. As a consequence, people building embedded systems will habitually strip them down to the absolute minimum. Finally, especially when talking battery powered devices, power consumption is usually a significant issue. If it isn't there, it can't consume power. If it can't consume power, a smaller and less heavy (and less expensive) battery can be used and recharge times may be reduced. And when micro energy harvesting enters the equation, this gets even more important. In "normal" IT it is generally reasonable to buy somewhat oversized because our systems tend to grow over time. Embedded systems built for a fixed purpose don't grow, so the entire way of thinking here is going exactly the opposite way we've been taught in our line of business. Operational aspects ------------------- Embedded systems frequently don't assume a system administrator to be around. They are built to be handled by ordinary end users, like you in your car, or an airline pilot in a---surprise---airliner. And despite various rumors, the onboard engineers of the past haven't been replaced by a system/network administrator. This means that embedded systems must frequently be built so people without any particular knowledge can safely and reliably operate them. This also applies to more mundane systems, like "smart" TVs or network controlled heating radiator valves or such. And when it comes to confronting end users with questions they can't possibly answer, simply because they don't have the necessary technical knowledge, that's enough for yet another thread---but not this time. System updates -------------- Updating an embedded system is troublesome in a number of ways. First of all, people frequently don't care about updates, as some recent events at least here in Germany have shown. My personal experience here is more from a security point of view; let's say that a customer of mine was kind of embarrassed when I happened to I mention security updates on network printers... Next, in a Harvard or even modified Harvard architecture, updates are difficult to implement. The larger AVR microcontrollers (see below) support the concept of a "management system" called a boot loader---which needs extra flash memory, of course. But to do an update it is necessary to trigger that update externally; there are no automatic updates. Even if there was a way to do automatic updates, how would one time them? Even a downtime of a few seconds may be unacceptable to your power brake system while in heavy traffic. As soon as embedded systems are used in critical environments, changes need to be tested, validated and certified. What's worse, if the functionality is "improved", things that can happen are shown for example here: http://en.wikipedia.org/wiki/Scandinavian_Airlines_Flight_751 Technical properties -------------------- While some embedded systems have significant computational power comparable to a full-blown computer, for example in the Linux-running ones, microcontrollers are generally more limited. Just to give you some ideas; I'll stick with the Atmel AVR line of microcontrollers, because I am most familiar with them and thanks to the Arduino line of prototyping boards they are best known in general. These are Harvard architecture devices, so they have separate (flash) memory for code, (static) RAM for volatile data and EEPROM for non-volatile data. And no, there's no MMU, memory caches or DRAM; which isn't altogether bad when building systems to hard realtime requirements. ATtiny13: 1 kB of flash memory, 64 bytes of RAM, 64 bytes of EEPROM 5/6 GPIO pins, no dedicated I/O hardware This is rather limited for any kind of communications, except maybe via bitbanging the GPIO pins. Yes, these devices are actually used. No, these are not the smallest ones available, but they are the smallest that can be programmed in-system. ATtiny25: 2 kB of flash memory, 128 bytes of RAM, 128 bytes of EEPROM 5/6 GPIO pins, alternatively used for I2C or SPI These can actually be put on an I2C or SPI bus and combined with I2C or SPI peripherals that way. It may be possible to use them with a USB or TCP/IP/Ethernet chip, but I don't have any reliable data, let alone personal experience, on this. ATtiny2313: 2 kB of flash memory, 128 bytes of RAM, 128 bytes of EEPROM 11/12 GPIO pins, alternatively used for I2C, SPI or U(S)ART These can also do serial communication (RS-232/422/485 using suitable driver chips. Even more interesting: With a few external components (Zener diodes and resistors?) they can also do USB in software, using about 1100 to 1300 bytes of their flash memory; search for V-USB for details. ATmega328: 32 kB flash, 2 kB RAM, 1 kB EEPROM 23 GPIO pins, alternatively used for I2C, SPI, U(S)ART Boot loader support These are used in the Arduino Uno board. Combined with a hardware TCP/IP/Ethernet chip like the Wiznet W5100, they can do TCP/IP. See below. ATmega1284: 128 kB flash, 16 kB RAM, 4 kB EEPROM. 32 GPIO pins, alternatively used for I2C, SPI, 2x U(S)ART Boot loader support The most powerful AVR microcontroller available in a DIP package. Beyond that, it is SMD only. But beyond this it's mostly more I/O stuff anyway. To add network capabilities, this requires some extra hardware except for the V-USB thing mentioned with the t2313. If you want to use the USARTs for RS-xxx: Maxim has a range of driver chips with built-in charge pumps to convert between TTL and RS-xxx voltages. In case you want to limit yourself to USB, take a look at the FTDI FT245BL. There are Ethernet-only chips like the ENC 28J60. According to a statement during the last IETF meeting in Berlin, it is possible to implement IPv6 with "only" 32 kB of flash and 4 kB of RAM. In other words, this is not an option for the Arduino Uno. The Wiznet W5100 used on the Arduino Ethernet shields implements IPv4 in hardware, or at least parts of it---among the things missing are for example fragmentation. So far I don't know of any similar chip implementing IPv6, let alone dual-stack. And to return to Yannis' original question: If I was to implement IPv6 in a setup like this I'd read the RFCs in question very closely---and then I'd take every simplification I could get away with. Hardcoding a /64 subnet prefix length in that implementation would be one I'd have absolutely no problem with; doing so would be standards compliant, save a few bytes of flash, and a lot of frustration for end users who in all likelyhood wouldn't know what value to set it to anyway, but try just about anything if things don't work out of the box. Cheers, Benedikt -- Business Grade IPv6 Consulting, Training, Projects Benedikt Stockebrand, Dipl.-Inform. http://www.stepladder-it.com/ From training at ripe.net Tue Oct 29 08:53:29 2013 From: training at ripe.net (Training Team) Date: Tue, 29 Oct 2013 08:53:29 +0100 Subject: [ipv6-wg] [training] RIPE NCC Webinars - new dates Message-ID: <526F6979.7020308@ripe.net> Dear colleagues, We are pleased to announce the launch of new dates for our Webinars. The RIPE NCC Webinars are live and take only one hour. You can interact with our trainers without leaving your desk. We focus on the topics and issues most important for LIRs. Register now at https://www.ripe.net/lir-services/training/e-learning/webinars Participation is limited to 20 people, so don't hesitate if you want to take part! If you have questions, please email . We look forward to seeing you online. Kind regards, RIPE NCC Training Services From leo.vegoda at icann.org Wed Oct 30 18:29:30 2013 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 30 Oct 2013 10:29:30 -0700 Subject: [ipv6-wg] 96 more bits... time for some magic after all? In-Reply-To: References: <20131025123700.07c155ed@earth.home.time-travellers.org> <87k3h1weyv.fsf@stepladder-it.com> <87ob6bkv25.fsf@stepladder-it.com> Message-ID: <5648A8908CCB564EBF46E2BC904A75B19680B6D234@EXVPMBX100-1.exc.icann.org> Hi Roger, Roger J?rgensen wrote: [...] > > Sorry, but I disagree on that. A /56 is fine for today's requirements, > > but if this hype about the "Internet of Things" really takes off and you > > want to put things into different subnets, a /56 may occasionally be a > > problem even for consumer households. Not today, but think anything > > from ten to fourty years. > > We'll have bigger problems, and other problems in 10years time. We > have probably start to use more than the 2000::/3 space for one thing. > That might change the game? If we need to start another /3 in just a decade's time then Internet growth will have been astronomical. There are currently 506 /12s available in 2000::/3 and to have allocated them all in a decade would mean allocating more than four per month. Even at a relatively sparse allocation density that would still require an Internet significantly more massive that what we currently have. Regards, Leo Vegoda -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5475 bytes Desc: not available URL: From bs at stepladder-it.com Thu Oct 31 17:17:52 2013 From: bs at stepladder-it.com (Benedikt Stockebrand) Date: Thu, 31 Oct 2013 16:17:52 +0000 Subject: [ipv6-wg] 96 more bits... time for some magic after all? In-Reply-To: ("Roger \=\?utf-8\?Q\?J\=C3\=B8rgensen\=22's\?\= message of "Sun, 27 Oct 2013 16:12:14 +0100") References: <20131025123700.07c155ed@earth.home.time-travellers.org> <87k3h1weyv.fsf@stepladder-it.com> <87ob6bkv25.fsf@stepladder-it.com> Message-ID: <87bo259zyn.fsf@stepladder-it.com> Roger J?rgensen writes: > We'll have bigger problems, and other problems in 10years time. We > have probably start to use more than the 2000::/3 space for one thing. > That might change the game? as Leo pointed out: Work the numbers. Then think about 4000::/3, 6000::/3, 8000::/3, a000::/3, c000::/3. >> I don't see any reason why size has to do with it. The problem is more >> of a ratio between size and allocated address space---and the technical >> knowledge around. (And no, unlike somebody else on this list I don't >> believe it feasible for a consumer to call in a CCIE every time they >> need some networked deviced hooked up.) > > are work ongoing elsewhere that maybe can fix that > connect-anything-anyway-you-like problem we've always had. But that's > not a policy question. I'm not sure if I get what you mean. But if you relate to the IETF homenet WG: From what I've seen they have very limited understanding of microcontrollers and apparently keep forgetting about their grandma (or whatever other archetypical non-tech end user). > [...] > agree, this /64 is one of the really really good thing. It can be > considered a waste of address space but it's a nice division between > net-prefix and LAN-prefix :-) What do you mean by "net-prefix" and "LAN-prefix"??? >>> * For one server running in the cloud I got a /112, that work just fine really. >> >> ...until you do an upgrade on the server that relies on RFC 4291. > > so what? I buy a service, and if the provider support me installing > something that break their setup, then it's really their problem. > > Pain is mine but problem is theirs to fix. As I pointed out elsewhere in this thread, anything but a /64 as subnet prefix length violates RFC 4291. The problem is yours. >>> * I have tried to use an entire /48 but failed. I tried to build my >>> own network with VPN, routings and everything across the different >>> servers and routers I have spread around. That /48 was big enough for >>> me:) >> >> Oha. So you have too many machines to fit into a /64 in a single >> subnet? > > No, I had enough of /64 in a /48. I tried to run out of /64's but > hadn't enough sites or enough machines. I really tried, even used /52, > /56 etc to :-) > The operating headache took me way before the address space was empty. > Could gone further with automaton but that wasn't the point. Sorry, I really don't understand what you try to say here. >>> * I tried to build a big routed, multisite network using a /56, that >>> also worked upto a certain size :) >> >> Sorry, I don't get what you want to say there. > > a /56 is plenty for most cases. However I was able to run out of > available /64 to use before the operating headache took me :-) > > I think that if an end-user ask for a /48 then the operators _should_ > provide you with a /48. ??? Cheers, Benedikt -- Business Grade IPv6 Consulting, Training, Projects Benedikt Stockebrand, Dipl.-Inform. http://www.stepladder-it.com/