From mir at ripe.net Wed Jun 1 16:52:44 2011 From: mir at ripe.net (Mirjam Kuehne) Date: Wed, 01 Jun 2011 16:52:44 +0200 Subject: [ipv6-wg] New article on RIPE Labs: Experimental NAT64/DNS64 Service at LITNET Message-ID: <4DE6523C.8070409@ripe.net> Dear colleagues, The Lithuanian research and education network LITNET and the Kaunas University of Technology provide an experimental NAT64/DNS64 service. Please find more information on RIPE Labs: http://labs.ripe.net/Members/raimis/experimental-nat64-dns64-service Kind regards, Mirjam Kuehne RIPE NCC From mir at ripe.net Mon Jun 6 08:33:51 2011 From: mir at ripe.net (Mirjam Kuehne) Date: Mon, 06 Jun 2011 08:33:51 +0200 Subject: [ipv6-wg] Asymmetric 6to4 measurements Message-ID: <4DEC74CF.9090601@ripe.net> [apologies for duplicates] Dear colleagues, In preparation for World IPv6 Day, Richard Barnes and Emile Aben have been working on measuring the impact of 6to4 on the latency of Internet traffic. This new article on RIPE Labs describes the measurement techniques and some initial findings: http://labs.ripe.net/Members/rbarnes/world-ipv6-day-asymmetric-6to4-measurements Kind Regards, Mirjam Kuehne RIPE NCC From jan at go6.si Mon Jun 6 16:23:40 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Mon, 06 Jun 2011 16:23:40 +0200 Subject: [ipv6-wg] New version (or followup) of RIPE-501 document... Message-ID: <4DECE2EC.8060600@go6.si> Dear RIPE IPv6 community. As promised, please find in attach new version (or followup) from RIPE-501 document. This document will get new version (if agreed in community) and will obsolete RIPE-501 as such. There is a promise, that RIPE-501 gets a link of new document, if/when that happens. What are major changes? We added CPE and mobile node requirements, we added some wording and explanations and we also took 2 options away, leaving with only 1 option. Main idea of new document is elaborated old option 3, in short: "Request IPv6 Ready Logo certificate, if equipment was not put under this testing require list of RFCs that needs to be supported. Note that IPv6 Ready Logo tests only basic requirements and if you have any special needs, request Logo and additional RFCs..." All is explained in a document. You'll see all possible colors in the docs. Black is what is left from original RIPE-501, different colors means different authors changes :) With this we hope to help you look at changes and spot them easily. There is .doc and .pdf versions attached. Authors would like to thnx all reviewers of this new document, we sent it firstly to all who contributed to previous version. You all know who you are :) Please, all comments and suggestions welcome and I expect vivid discussion here on the list. Goal is to try to reach a consensus for November RIPE meeting, if possible. Cheers from hard working ex-501 team - Merike, Sander and Jan -------------- next part -------------- A non-text attachment was scrubbed... Name: Requirements-for-IPv6-in-ICT-equipment-v.1.pdf Type: application/pdf Size: 291181 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Requirements-for-IPv6-in-ICT-equipment-v.1.doc Type: application/msword Size: 411136 bytes Desc: not available URL: From erica.johnson at iol.unh.edu Mon Jun 6 17:04:34 2011 From: erica.johnson at iol.unh.edu (Erica Johnson) Date: Mon, 6 Jun 2011 11:04:34 -0400 Subject: [ipv6-wg] Re: [ipv6ready-tech:5118] New version (or followup) of RIPE-501 document... In-Reply-To: <4DECE2EC.8060600@go6.si> References: <4DECE2EC.8060600@go6.si> Message-ID: <067948B0-E5F7-4167-A479-6169B1A837F2@iol.unh.edu> Hi Jan, I've attached an updated version with my comments regarding Logo test support (*). There were a couple more RFCs supported in the testing. Best Regards, Erica -------------- next part -------------- A non-text attachment was scrubbed... Name: Requirements-for-IPv6-in-ICT-equipment-v.2.doc Type: application/msword Size: 267776 bytes Desc: not available URL: -------------- next part -------------- On Jun 6, 2011, at 10:23 AM, Jan Zorz @ go6.si wrote: > Dear RIPE IPv6 community. > > As promised, please find in attach new version (or followup) from RIPE-501 document. > > This document will get new version (if agreed in community) and will obsolete RIPE-501 as such. There is a promise, that RIPE-501 gets a link of new document, if/when that happens. > > What are major changes? We added CPE and mobile node requirements, we added some wording and explanations and we also took 2 options away, leaving with only 1 option. > > Main idea of new document is elaborated old option 3, in short: > > "Request IPv6 Ready Logo certificate, if equipment was not put under this testing require list of RFCs that needs to be supported. Note that IPv6 Ready Logo tests only basic requirements and if you have any special needs, request Logo and additional RFCs..." > > All is explained in a document. > > You'll see all possible colors in the docs. Black is what is left from original RIPE-501, different colors means different authors changes :) With this we hope to help you look at changes and spot them easily. > > There is .doc and .pdf versions attached. > > Authors would like to thnx all reviewers of this new document, we sent it firstly to all who contributed to previous version. You all know who you are :) > > Please, all comments and suggestions welcome and I expect vivid discussion here on the list. Goal is to try to reach a consensus for November RIPE meeting, if possible. > > Cheers from hard working ex-501 team - Merike, Sander and Jan > Erica Johnson, Director UNH InterOperability Laboratory (UNH-IOL) o: 1.603.862.0117 m: 1.603.421.4802 http://www.iol.unh.edu -------------- next part -------------- A non-text attachment was scrubbed... Name: facebook-scaled.png Type: image/png Size: 4437 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: twitter-scaled.png Type: image/png Size: 4659 bytes Desc: not available URL: -------------- next part -------------- From jan at go6.si Tue Jun 7 08:39:55 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Tue, 07 Jun 2011 08:39:55 +0200 Subject: [ipv6-wg] Re: [ipv6ready-tech:5118] New version (or followup) of RIPE-501 document... In-Reply-To: <067948B0-E5F7-4167-A479-6169B1A837F2@iol.unh.edu> References: <4DECE2EC.8060600@go6.si> <067948B0-E5F7-4167-A479-6169B1A837F2@iol.unh.edu> Message-ID: <4DEDC7BB.4050009@go6.si> On 6/6/11 5:04 PM, Erica Johnson wrote: > Hi Jan, > > I've attached an updated version with my comments regarding Logo test support (*). There were a couple more RFCs supported in the testing. Erica, thnx for corrections, inserted in main document :) Cheers, Jan From marcoh at marcoh.net Tue Jun 7 08:08:57 2011 From: marcoh at marcoh.net (Marco Hogewoning) Date: Tue, 7 Jun 2011 10:08:57 +0400 Subject: [ipv6-wg] Re: [ipv6ready-tech:5118] New version (or followup) of RIPE-501 document... In-Reply-To: <067948B0-E5F7-4167-A479-6169B1A837F2@iol.unh.edu> References: <4DECE2EC.8060600@go6.si> <067948B0-E5F7-4167-A479-6169B1A837F2@iol.unh.edu> Message-ID: <0C33D92B-CA3F-4317-921C-2B3D88AF73B1@marcoh.net> Hi Working group, First of all, apologies to you Erica. By no means trying to pick on you. May I request people to post clear text comments to the list and leave the actual document editing to the original authors. Not everybody runs Word or other proprietary software and we want to keep this working group open to everybody. It also makes it easier to track changes and versions. Thanks, MarcoH IPv6 Working Group co-chair From marcoh at marcoh.net Tue Jun 7 09:19:50 2011 From: marcoh at marcoh.net (Marco Hogewoning) Date: Tue, 7 Jun 2011 11:19:50 +0400 Subject: [ipv6-wg] New version (or followup) of RIPE-501 document... In-Reply-To: <4DECE2EC.8060600@go6.si> References: <4DECE2EC.8060600@go6.si> Message-ID: <26892F2C-E8DD-40E8-8F3F-E27E970A4A0A@marcoh.net> Dear Colleagues, We had a quick chat with the original authors on how the process should look. As this document in itself does not try to set or modify policy, we are not going to formally apply the Policy Development Process on it. However we do want to structure the work a bit so it has been proposed to use similar timelines. The authors have agreed on a four week "review" period of the current draft. If you have any comments or additions regarding this document please make these known to the mailing list or the authors before Tuesday July 5th 2011. After this date the suggestions will be processed and a new version will be published to reflect the discussion that hopefully took place. We would also kindly ask you to voice your support of this document when you agree to the proposed text. This will help us to move forward knowing there is community support to publish a new version of the ripe-501 document. Thanks, The IPv6 WG chairs, Marco, Shane and David From robert at ripe.net Tue Jun 7 09:02:08 2011 From: robert at ripe.net (Robert Kisteleki) Date: Tue, 07 Jun 2011 09:02:08 +0200 Subject: [ipv6-wg] v6day.ripe.net Message-ID: <4DEDCCF0.7060106@ripe.net> Our dashboard for world IPv6 day is now officially open at http://v6day.ripe.net/ It leads to loads of statistical and diagnostic information. We are still tweaking it a little and adding things. Enjoy Robert From marcoh at marcoh.net Tue Jun 7 10:08:34 2011 From: marcoh at marcoh.net (Marco Hogewoning) Date: Tue, 7 Jun 2011 12:08:34 +0400 Subject: [ipv6-wg] v6day.ripe.net In-Reply-To: <4DEDCCF0.7060106@ripe.net> References: <4DEDCCF0.7060106@ripe.net> Message-ID: <39F6A6F7-4710-4541-9281-959EFBB893E0@marcoh.net> On Jun 7, 2011, at 11:02 AM, Robert Kisteleki wrote: > Our dashboard for world IPv6 day is now officially open at > > http://v6day.ripe.net/ > > It leads to loads of statistical and diagnostic information. > We are still tweaking it a little and adding things. > > Enjoy > > Robert Looks like somebody is doing test runs across ams-ix or did some private peering flap ? Anybody in the EIX community that sees the same or who can shed some light on this ? Marco (just a curious citizen) From achatz at forthnet.gr Tue Jun 7 10:11:48 2011 From: achatz at forthnet.gr (Tassos Chatzithomaoglou) Date: Tue, 07 Jun 2011 11:11:48 +0300 Subject: [ipv6-wg] v6day.ripe.net In-Reply-To: <4DEDCCF0.7060106@ripe.net> References: <4DEDCCF0.7060106@ripe.net> Message-ID: <4DEDDD44.50501@forthnet.gr> Excellent! Any idea what happened on AMS-IX? Did someone started testing one day earlier? -- Tassos Robert Kisteleki wrote on 07/06/2011 10:02: > Our dashboard for world IPv6 day is now officially open at > > http://v6day.ripe.net/ > > It leads to loads of statistical and diagnostic information. > We are still tweaking it a little and adding things. > > Enjoy > > Robert > > > From eimann at etherkiller.de Tue Jun 7 10:12:11 2011 From: eimann at etherkiller.de (Dominik Bay) Date: Tue, 7 Jun 2011 10:12:11 +0200 Subject: [ipv6-wg] v6day.ripe.net In-Reply-To: <39F6A6F7-4710-4541-9281-959EFBB893E0@marcoh.net> References: <4DEDCCF0.7060106@ripe.net> <39F6A6F7-4710-4541-9281-959EFBB893E0@marcoh.net> Message-ID: On Tue, Jun 7, 2011 at 10:08, Marco Hogewoning wrote: > Looks like somebody is doing test runs across ams-ix or did some private peering flap ? Anybody in the EIX community that sees the same or who can shed some light on this ? According to a source on IRC it was a measurement error (confirmed by an AMS-IX statement). -dominik From arien.vijn at ams-ix.net Tue Jun 7 10:13:30 2011 From: arien.vijn at ams-ix.net (Arien Vijn) Date: Tue, 7 Jun 2011 10:13:30 +0200 Subject: [ipv6-wg] v6day.ripe.net In-Reply-To: <39F6A6F7-4710-4541-9281-959EFBB893E0@marcoh.net> References: <4DEDCCF0.7060106@ripe.net> <39F6A6F7-4710-4541-9281-959EFBB893E0@marcoh.net> Message-ID: <4E79F36B-9C8B-4AAD-A5A4-76259DE66B65@ams-ix.net> On 7 Jun 2011 (24), at 10:08 AM, Marco Hogewoning wrote: > Looks like somebody is doing test runs across ams-ix or did some private peering flap ? Anybody in the EIX community that sees the same or who can shed some light on this ? It was test traffic and should not have been counted. We are working to subtract it from the real traffic. -- Arien -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1305 bytes Desc: not available URL: From shane at time-travellers.org Tue Jun 7 11:24:57 2011 From: shane at time-travellers.org (Shane Kerr) Date: Tue, 07 Jun 2011 11:24:57 +0200 Subject: [ipv6-wg] IPv6 World Day prep behind a crappy hotel DNS resolver Message-ID: <1307438699.23545.20.camel@localhost.localdomain> Hello, IPv6 World Day is tomorrow! I'm at the ENOG meeting in Moscow, which has a pretty common hotel Internet setup - a web redirect on first connect and then some magic somewhere records your information so you get out to the Internet more-or-less directly from then on. Someone at the meeting was kind enough to set up IPv6 service here. Yesterday it seemed a bit bumpy, but today it is working nicely. However, the network has a somewhat broken DNS resolver, which is also sadly pretty common at hotels. It seems to have problems answering normal IPv4 address queries (A records), but mostly works for that. It does not handle IPv6 address queries (AAAA records) at all. :( I tried running a resolver on my laptop, but the hotel network restricts DNS UDP packets to a maximum of 512 bytes. Even worse, it truncates larger answers to that size, and does not set the truncate bit. This confuses BIND mightily, as you would expect, since it is basically getting corrupted packets. Plus it blocks DNS TCP completely. Suffice it to say IPv4 is damaged here. A quick Google reveals that OpenDNS has IPv6 servers, which allows me to use the IPv6 transit, which is free of nonsensical tampering: http://warrenkwok.blogspot.com/2011/05/opendns-offers-ipv6-resolvers.html The IPv6 eyechart is now a sea of green! I'm ready for tomorrow. Are you? :) -- Shane From millnert at gmail.com Tue Jun 7 16:52:13 2011 From: millnert at gmail.com (Martin Millnert) Date: Tue, 7 Jun 2011 10:52:13 -0400 Subject: [ipv6-wg] v6day.ripe.net In-Reply-To: <4DEDCCF0.7060106@ripe.net> References: <4DEDCCF0.7060106@ripe.net> Message-ID: Hi, cool dashboard! Thanks. I was wondering if you have considered (or could consider) also adding tracepath6 / scamper pmtu discovery probes to the measurements as well in some fashion. A non-trivial exercise, I'm sure. Would be quite useful, I imagine. Cheers, Martin On Tue, Jun 7, 2011 at 3:02 AM, Robert Kisteleki wrote: > Our dashboard for world IPv6 day is now officially open at > > ? ? ? ?http://v6day.ripe.net/ > > It leads to loads of statistical and diagnostic information. > We are still tweaking it a little and adding things. > > Enjoy > > Robert > > From robert at ripe.net Tue Jun 7 17:39:00 2011 From: robert at ripe.net (Robert Kisteleki) Date: Tue, 07 Jun 2011 17:39:00 +0200 Subject: [ipv6-wg] v6day.ripe.net In-Reply-To: References: <4DEDCCF0.7060106@ripe.net> Message-ID: <4DEE4614.4070004@ripe.net> Hi, On 2011.06.07. 16:52, Martin Millnert wrote: > Hi, > > cool dashboard! Thanks. > > > I was wondering if you have considered (or could consider) also adding > tracepath6 / scamper pmtu discovery probes to the measurements as well > in some fashion. A non-trivial exercise, I'm sure. > > Would be quite useful, I imagine. > > Cheers, > Martin Considering the fact that we are at T-8h or so, I think we'll look into implementing this next time :-) Regards, Robert From millnert at gmail.com Wed Jun 8 05:29:27 2011 From: millnert at gmail.com (Martin Millnert) Date: Tue, 7 Jun 2011 23:29:27 -0400 Subject: [ipv6-wg] v6day.ripe.net In-Reply-To: <4DEE4614.4070004@ripe.net> References: <4DEDCCF0.7060106@ripe.net> <4DEE4614.4070004@ripe.net> Message-ID: Robert, On Tue, Jun 7, 2011 at 11:39 AM, Robert Kisteleki wrote: > Hi, > > On 2011.06.07. 16:52, Martin Millnert wrote: >> Hi, >> >> cool dashboard! Thanks. >> >> >> I was wondering if you have considered (or could consider) also adding >> tracepath6 / scamper pmtu discovery probes to the measurements as well >> in some fashion. ?A non-trivial exercise, I'm sure. >> >> Would be quite useful, I imagine. >> >> Cheers, >> Martin > > Considering the fact that we are at T-8h or so, I think we'll look into > implementing this next time :-) Fair enough :) I was just wondering if you had it already just waiting to push the big launch button. So now that the measurements are ongoing and I see like ~everyone is using akamai proxies, and the overall relative RTT is ~0.8, I have a request which is pretty reasonable i think (which should be easy enough to do in post-processing): Group a summarized relative RTT stats graph by those who use Akamai for this and those who don't, to effectively benchmark their service/peering/ etc. (Obviously, since so many sites use the same single provider for this day, that single provider influences stats a lot). Best, Martin From robert at ripe.net Wed Jun 8 08:01:58 2011 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 08 Jun 2011 08:01:58 +0200 Subject: [ipv6-wg] v6day.ripe.net In-Reply-To: References: <4DEDCCF0.7060106@ripe.net> <4DEE4614.4070004@ripe.net> Message-ID: <4DEF1056.1030006@ripe.net> > So now that the measurements are ongoing and I see like ~everyone is > using akamai proxies, and the overall relative RTT is ~0.8, I have a > request which is pretty reasonable i think (which should be easy > enough to do in post-processing): > > Group a summarized relative RTT stats graph by those who use Akamai > for this and those who don't, to effectively benchmark their > service/peering/ etc. (Obviously, since so many sites use the same > single provider for this day, that single provider influences stats a > lot). We have the data and plan to do a number of post-op analyses. We'll take your idea on board as inspiration! Cheers, Robert From ahmed at tamkien.com Wed Jun 8 10:55:14 2011 From: ahmed at tamkien.com (Ahmed Abu-Abed) Date: Wed, 8 Jun 2011 11:55:14 +0300 Subject: [ipv6-wg] Rapid IPv6 deployment for World IPv6 Day Message-ID: <7CABE1C6487D40D381E561A114A0BF3A@mTOSH> Hello, To setup a computer with IPv6 public address over any IPv4 connection (3G, ADSL, dial-up, etc. and even behind nested NATs) for World IPv6 Day testing then I suggest downloading the Freenet6 client and running it with default settings; it's the closest you can get to plug and play IPv6. Freenet6 have the TSP protocol IPv6 server in Amsterdam, so response times should be acceptable. Only the Windows XP/Vista/7 versions have an intuitive graphical interface, while OS X, BSD and Linux are command line only so far. Register and download the client from http://gogonet.gogo6.com/page/freenet6-ipv6-services Its working very well at my end today, with standard pings to Facebook, Bing, Yahoo and Google defaulting to IPv6 addresses and responses when connected to Freenet6. Regards, -Ahmed -------------- next part -------------- An HTML attachment was scrubbed... URL: From millnert at gmail.com Wed Jun 8 14:38:55 2011 From: millnert at gmail.com (Martin Millnert) Date: Wed, 8 Jun 2011 08:38:55 -0400 Subject: [ipv6-wg] v6day.ripe.net In-Reply-To: <4DEF1056.1030006@ripe.net> References: <4DEDCCF0.7060106@ripe.net> <4DEE4614.4070004@ripe.net> <4DEF1056.1030006@ripe.net> Message-ID: Robert, great! On Wed, Jun 8, 2011 at 2:01 AM, Robert Kisteleki wrote: >> So now that the measurements are ongoing and I see like ~everyone is >> using akamai proxies, and the overall relative RTT is ~0.8, I have a >> request which is pretty reasonable i think (which should be easy >> enough to do in post-processing): >> >> Group a summarized relative RTT stats graph by those who use Akamai >> for this and those who don't, to effectively benchmark their >> service/peering/ etc. ?(Obviously, since so many sites use the same >> single provider for this day, that single provider influences stats a >> lot). > > We have the data and plan to do a number of post-op analyses. We'll take > your idea on board as inspiration! > I realize there are two kinds of usage going on, which I'm sure you do too: 1) akadns for geolocation (I presume), 2) actually serving pages from akamai Would be interesting to hear more from them. Cheers, Martin From noreply at ripe.net Wed Jun 8 14:29:16 2011 From: noreply at ripe.net (Axel Pawlik) Date: Wed, 08 Jun 2011 14:29:16 +0200 Subject: [ipv6-wg] World IPv6 Day and the RIPE NCC Message-ID: <4DEF6B1C.3060603@ripe.net> [Apologies for duplicate emails] Dear colleagues, The RIPE NCC is proud to participate in today's World IPv6 Day, a global event in which many organisations around the world are offering their content over IPv6. All of the RIPE NCC?s services and content have already been available over IPv6 for some time. We are also taking part in events in Amsterdam and Moscow, as well as conducting a wide range of IPv6-related measurements and analysis. IPv6 Eye Chart ============== If you want to find out if you will have problems accessing websites during World IPv6 Day, you can use the IPv6 Eye Chart: http://ipv6eyechart.ripe.net/ World IPv6 Day Dashboard ======================== All the IPv6 measurements carried out by the RIPE NCC are available at: http://v6day.ripe.net Amsterdam Event =============== The World IPv6 Day event in Amsterdam features tutorials, workshops, panel discussions and keynote speeches on IPv6. You can follow the event live at: http://webcolleges.uva.nl/mediasite/Viewer/?peid=bee87df6f35d4943adaff2ad9874af2b1d Moscow Event ============ World IPv6 Day is being celebrated during the RIPE Day at the first meeting of the Eurasia Network Operators Group (ENOG), taking place in Moscow. Throughout the day, there will be IPv6-related presentations, a special meeting for the press and screens tracking the measurements being conducted by the RIPE NCC. A webcast of the event is available at: http://www.enog.org/programme/webcast/ Best regards, Axel Pawlik Managing Director RIPE NCC From jan at go6.si Thu Jun 16 10:31:00 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Thu, 16 Jun 2011 10:31:00 +0200 Subject: [ipv6-wg] New version (or followup) of RIPE-501 document... In-Reply-To: <26892F2C-E8DD-40E8-8F3F-E27E970A4A0A@marcoh.net> References: <4DECE2EC.8060600@go6.si> <26892F2C-E8DD-40E8-8F3F-E27E970A4A0A@marcoh.net> Message-ID: <4DF9BF44.2010706@go6.si> On 6/7/11 9:19 AM, Marco Hogewoning wrote: > We would also kindly ask you to voice your support of this document when you agree to the proposed text. This will help us to move forward knowing there is community support to publish a new version of the ripe-501 document. Dear v6 WG :) Wv6Day is over and we are switching back to regular schedule. We received some off-list comments for RIPE-501 followup (or next version) document, but we would like to encourage more people to read the draft, posted here on 6.6.2011 and comment - or express support if they agree with the text. There is at least one voting point in the draft, which CPE spec variant should we leave in the final doc and we need your input on that. We like both of them, which one you prefer? Thnx and cheers from the authors, Merike, Sander and Jan From mir at ripe.net Fri Jun 17 14:39:22 2011 From: mir at ripe.net (Mirjam Kuehne) Date: Fri, 17 Jun 2011 14:39:22 +0200 Subject: [ipv6-wg] New article on RIPE Labs: Measuring World IPv6 Day Message-ID: <4DFB4AFA.9090901@ripe.net> [apologies for duplicates] Dear colleagues, The RIPE NCC took a number of measurements both before and during World IPv6 Day. We've done an initial analysis of the data and would like to share our first impressions and results with you on RIPE Labs: http://labs.ripe.net/Members/mirjam/measuring-world-ipv6-day-first-impressions Kind Regards, Mirjam Kuehne RIPE Labs From kzorba at otenet.gr Fri Jun 17 14:08:14 2011 From: kzorba at otenet.gr (Kostas Zorbadelos) Date: Fri, 17 Jun 2011 15:08:14 +0300 Subject: [ipv6-wg] New version (or followup) of RIPE-501 document... In-Reply-To: <4DF9BF44.2010706@go6.si> References: <4DECE2EC.8060600@go6.si> <26892F2C-E8DD-40E8-8F3F-E27E970A4A0A@marcoh.net> <4DF9BF44.2010706@go6.si> Message-ID: <4DFB43AE.1080006@otenet.gr> On 06/16/2011 11:31 AM, Jan Zorz @ go6.si wrote: > On 6/7/11 9:19 AM, Marco Hogewoning wrote: Greetings to all, >> We would also kindly ask you to voice your support of this document >> when you agree to the proposed text. This will help us to move forward >> knowing there is community support to publish a new version of the >> ripe-501 document. > Dear v6 WG :) > > Wv6Day is over and we are switching back to regular schedule. > > We received some off-list comments for RIPE-501 followup (or next > version) document, but we would like to encourage more people to read > the draft, posted here on 6.6.2011 and comment - or express support if > they agree with the text. > > There is at least one voting point in the draft, which CPE spec variant > should we leave in the final doc and we need your input on that. We like > both of them, which one you prefer? > My personal preference is variant 2. Less text is good I think. A more general question regarding this work is, would you consider "load balancers" as network elements that should be included? I know that load balancing can also be achieved at the application layer, but in the v4 world there are dedicated appliances that provide the functionality and are considered network infrastructure elements. Finally, since I don't have the technical expertise to thoroughly verify the lists of RFCs mentioned, a comment for the writing structure of the document. I can imagine that this is still work in progress but I find the document difficult to read with this structure. Certainly having a table of contents with sections and subsections will help. > Thnx and cheers from the authors, Merike, Sander and Jan > Regards and thanks for the very good work. Kostas Zorbadelos From jan at go6.si Fri Jun 17 17:05:55 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Fri, 17 Jun 2011 17:05:55 +0200 Subject: [ipv6-wg] New version (or followup) of RIPE-501 document... In-Reply-To: <4DFB43AE.1080006@otenet.gr> References: <4DECE2EC.8060600@go6.si> <26892F2C-E8DD-40E8-8F3F-E27E970A4A0A@marcoh.net> <4DF9BF44.2010706@go6.si> <4DFB43AE.1080006@otenet.gr> Message-ID: <4DFB6D53.1070401@go6.si> On 6/17/11 2:08 PM, Kostas Zorbadelos wrote: > My personal preference is variant 2. Less text is good I think. Agree to some extent... What does one RFC means to procurement people and how they check if CPE fits the requirements? In this case procurement guy needs to interpret all requirements from one RFC instead of the given list. still not sure... > A more general question regarding this work is, would you consider "load > balancers" as network elements that should be included? > I know that load balancing can also be achieved at the application > layer, but in the v4 world there are dedicated appliances that provide > the functionality and are considered network infrastructure elements. Interesting, we got this conversation with F5 guy in London this week. Maybe we could :) > > Finally, since I don't have the technical expertise to thoroughly verify > the lists of RFCs mentioned, a comment for the writing structure of the > document. I can imagine that this is still work in progress but I find > the document difficult to read with this structure. Certainly having a > table of contents with sections and subsections will help. Table of contents is coming in last version, but if community thinks in general that table of contents would help then we could make an effort and do it now... /jan From jan at go6.si Fri Jun 17 17:10:01 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Fri, 17 Jun 2011 17:10:01 +0200 Subject: [ipv6-wg] New version (or followup) of RIPE-501 document... In-Reply-To: <4DFB43AE.1080006@otenet.gr> References: <4DECE2EC.8060600@go6.si> <26892F2C-E8DD-40E8-8F3F-E27E970A4A0A@marcoh.net> <4DF9BF44.2010706@go6.si> <4DFB43AE.1080006@otenet.gr> Message-ID: <4DFB6E49.40102@go6.si> BTW, just to let you know, there is a Cisco position paper on RIPE-501 :) http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6553/brief_c80-674464.html We should probably address their comments, specially the one that talks about RFC sets: "In option 1, RIPE-501 cherry-picks requirements from USGv6 and then adds its own without enough justification. We think that weakens the credibility of the document." We got solid consensus on RFC sets and changes were not taken "out-of-the-blue". I think we need to stress out this fact in the document. Any suggestions? /jan From ot at cisco.com Sat Jun 18 20:11:47 2011 From: ot at cisco.com (Ole Troan) Date: Sat, 18 Jun 2011 20:11:47 +0200 Subject: [ipv6-wg] New version (or followup) of RIPE-501 document... In-Reply-To: <4DFB6D53.1070401@go6.si> References: <4DECE2EC.8060600@go6.si> <26892F2C-E8DD-40E8-8F3F-E27E970A4A0A@marcoh.net> <4DF9BF44.2010706@go6.si> <4DFB43AE.1080006@otenet.gr> <4DFB6D53.1070401@go6.si> Message-ID: <474259A9-0A44-4D52-90A1-F218889B994A@cisco.com> Jan, >> My personal preference is variant 2. Less text is good I think. > > Agree to some extent... > > What does one RFC means to procurement people and how they check if CPE fits the requirements? In this case procurement guy needs to interpret all requirements from one RFC instead of the given list. > > still not sure... RFC6104 _is_ just that; a device profile to be used for procurement. replicating this work in RIPE-501 seems redundant and more cause for confusion than help. we do after all have 3 of the IPv6 CPE profiles now. eRouter from CableLabs, TR-124i2 from BroadbandForum and RFC6104 from the IETF. cheers, Ole From jan at go6.si Sun Jun 19 10:39:40 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Sun, 19 Jun 2011 10:39:40 +0200 Subject: [ipv6-wg] New version (or followup) of RIPE-501 document... In-Reply-To: <474259A9-0A44-4D52-90A1-F218889B994A@cisco.com> References: <4DECE2EC.8060600@go6.si> <26892F2C-E8DD-40E8-8F3F-E27E970A4A0A@marcoh.net> <4DF9BF44.2010706@go6.si> <4DFB43AE.1080006@otenet.gr> <4DFB6D53.1070401@go6.si> <474259A9-0A44-4D52-90A1-F218889B994A@cisco.com> Message-ID: <4DFDB5CC.3010709@go6.si> On 6/18/11 8:11 PM, Ole Troan wrote: > Jan, > >>> My personal preference is variant 2. Less text is good I think. >> >> Agree to some extent... >> >> What does one RFC means to procurement people and how they check if CPE fits the requirements? In this case procurement guy needs to interpret all requirements from one RFC instead of the given list. >> >> still not sure... > > RFC6104 _is_ just that; a device profile to be used for procurement. > replicating this work in RIPE-501 seems redundant and more cause for confusion than help. we do after all have 3 of the IPv6 CPE profiles now. eRouter from CableLabs, TR-124i2 from BroadbandForum and RFC6104 from the IETF. ok, so I understand this as vote for variant 2. :) anyone else care for voting? Ole, don't get me wrong, We are just doing the sanity check with community. Less text is more. /jan From marcoh at marcoh.net Sun Jun 19 11:34:05 2011 From: marcoh at marcoh.net (Marco Hogewoning) Date: Sun, 19 Jun 2011 12:34:05 +0300 Subject: [ipv6-wg] New version (or followup) of RIPE-501 document... In-Reply-To: <4DFDB5CC.3010709@go6.si> References: <4DECE2EC.8060600@go6.si> <26892F2C-E8DD-40E8-8F3F-E27E970A4A0A@marcoh.net> <4DF9BF44.2010706@go6.si> <4DFB43AE.1080006@otenet.gr> <4DFB6D53.1070401@go6.si> <474259A9-0A44-4D52-90A1-F218889B994A@cisco.com> <4DFDB5CC.3010709@go6.si> Message-ID: <8AFD9F5F-6FC9-4BAC-8736-7FFCC0E995F1@marcoh.net> On Jun 19, 2011, at 11:39 AM, Jan Zorz @ go6.si wrote: > On 6/18/11 8:11 PM, Ole Troan wrote: >> Jan, >> >>>> My personal preference is variant 2. Less text is good I think. >>> >>> Agree to some extent... >>> >>> What does one RFC means to procurement people and how they check if CPE fits the requirements? In this case procurement guy needs to interpret all requirements from one RFC instead of the given list. >>> >>> still not sure... >> >> RFC6104 _is_ just that; a device profile to be used for procurement. >> replicating this work in RIPE-501 seems redundant and more cause for confusion than help. we do after all have 3 of the IPv6 CPE profiles now. eRouter from CableLabs, TR-124i2 from BroadbandForum and RFC6104 from the IETF. > > ok, so I understand this as vote for variant 2. :) > > anyone else care for voting? > > Ole, don't get me wrong, We are just doing the sanity check with community. Less text is more. On a personal note: I agree with Ole, it is redundant to split it all up and in the long run it could also lead to discrepancies between the two. Stick with referring to 6104 and be done with it. Questions or comments on the exact profile can be directed at the IETF, making it the same with the references to 3Gpp. Marco From jan at pragma.si Sun Jun 19 14:06:06 2011 From: jan at pragma.si (Jan Zorz) Date: Sun, 19 Jun 2011 14:06:06 +0200 Subject: [ipv6-wg] New version (or followup) of RIPE-501 document... In-Reply-To: <8AFD9F5F-6FC9-4BAC-8736-7FFCC0E995F1@marcoh.net> References: <4DECE2EC.8060600@go6.si> <26892F2C-E8DD-40E8-8F3F-E27E970A4A0A@marcoh.net> <4DF9BF44.2010706@go6.si> <4DFB43AE.1080006@otenet.gr> <4DFB6D53.1070401@go6.si> <474259A9-0A44-4D52-90A1-F218889B994A@cisco.com> <4DFDB5CC.3010709@go6.si> <8AFD9F5F-6FC9-4BAC-8736-7FFCC0E995F1@marcoh.net> Message-ID: <4DFDE62E.5070306@pragma.si> On 6/19/11 11:34 AM, Marco Hogewoning wrote: > On a personal note: I agree with Ole, it is redundant to split it all up and in the long run it could also lead to discrepancies between the two. Stick with referring to 6104 and be done with it. Questions or comments on the exact profile can be directed at the IETF, making it the same with the references to 3Gpp. Taken into account. 3:0 for short text. /jan From tjc at ecs.soton.ac.uk Mon Jun 20 11:40:09 2011 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Mon, 20 Jun 2011 10:40:09 +0100 Subject: [ipv6-wg] New version (or followup) of RIPE-501 document... In-Reply-To: <474259A9-0A44-4D52-90A1-F218889B994A@cisco.com> References: <4DECE2EC.8060600@go6.si> <26892F2C-E8DD-40E8-8F3F-E27E970A4A0A@marcoh.net> <4DF9BF44.2010706@go6.si> <4DFB43AE.1080006@otenet.gr> <4DFB6D53.1070401@go6.si> <474259A9-0A44-4D52-90A1-F218889B994A@cisco.com> <21D352FB-79DE-4426-B6C1-20D7C2235901@ecs.soton.ac.uk> Message-ID: On 18 Jun 2011, at 19:11, Ole Troan wrote: > Jan, > >>> My personal preference is variant 2. Less text is good I think. >> >> Agree to some extent... >> >> What does one RFC means to procurement people and how they check if CPE fits the requirements? In this case procurement guy needs to interpret all requirements from one RFC instead of the given list. >> >> still not sure... > > RFC6104 _is_ just that; a device profile to be used for procurement. Actually, RFC6104 is something I know well, and it's not that. I think you mean RFC 6204 ;) I agree with Ole that replication is unnecessary. But if the RIPE community has differences to that list, it should state them. I don't think that 'weakens' 501-bis, rather it shows the operator community has genuine needs that differ from this and it would be prudent of vendors to take note of those needs. Note also that a very good reason for differences is that an 'advanced' CPE draft is in progress (draft-wbeebee-v6ops-ipv6-cpe-router-bis-04) which will have additional requirements, so perhaps 501-bis needs to decide if its idea of a CPE is that of 6204, or whether some things in the advanced draft need to be captured in 501-bis (which it seems they do). I think load balancers should be included; I know some universities who did not take part in W6D not because their web servers couldn't be made v6 ready, but because their load balancers could not. Some comments; I've not read the new text in detail (yet). Switches: - add RA-Guard (RFC 6105 I think) Routers: - what about multicast routing? Searching on multicast in the text only seems to produce MLDv2 (which imo is a mandatory everywhere). - Embedded-RP is a must for multicast routing Firewalls: - surprised SeND is optional - if we're adding mobile nodes, we need the vendor and admin firewall drafts? But draft-ietf-mext-firewall-vendor-04 and draft-ietf-mext-firewall-admin-04 would definitely be optional unless you must have MIPv6 running Tim From ip at ioshints.info Mon Jun 20 11:49:24 2011 From: ip at ioshints.info (Ivan Pepelnjak) Date: Mon, 20 Jun 2011 11:49:24 +0200 Subject: [ipv6-wg] New version (or followup) of RIPE-501 document... In-Reply-To: <4DFDE62E.5070306@pragma.si> References: <4DECE2EC.8060600@go6.si> <26892F2C-E8DD-40E8-8F3F-E27E970A4A0A@marcoh.net> <4DF9BF44.2010706@go6.si> <4DFB43AE.1080006@otenet.gr> <4DFB6D53.1070401@go6.si> <474259A9-0A44-4D52-90A1-F218889B994A@cisco.com> <4DFDB5CC.3010709@go6.si> <8AFD9F5F-6FC9-4BAC-8736-7FFCC0E995F1@marcoh.net> <4DFDE62E.5070306@pragma.si> Message-ID: <00a101cc2f2f$5876f0a0$0964d1e0$@info> 4:0 for the short text. > -----Original Message----- > From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of > Jan Zorz > Sent: Sunday, June 19, 2011 2:06 PM > To: ipv6-wg at ripe.net > Subject: Re: [ipv6-wg] New version (or followup) of RIPE-501 document... > > On 6/19/11 11:34 AM, Marco Hogewoning wrote: > > On a personal note: I agree with Ole, it is redundant to split it all up > and in the long run it could also lead to discrepancies between the two. > Stick with referring to 6104 and be done with it. Questions or comments on > the exact profile can be directed at the IETF, making it the same with the > references to 3Gpp. > Taken into account. > > 3:0 for short text. > > /jan From us at sweet-sorrow.com Mon Jun 20 11:52:52 2011 From: us at sweet-sorrow.com (Us) Date: Mon, 20 Jun 2011 11:52:52 +0200 Subject: [ipv6-wg] New version (or followup) of RIPE-501 document... In-Reply-To: <00a101cc2f2f$5876f0a0$0964d1e0$@info> References: <4DECE2EC.8060600@go6.si> <26892F2C-E8DD-40E8-8F3F-E27E970A4A0A@marcoh.net> <4DF9BF44.2010706@go6.si> <4DFB43AE.1080006@otenet.gr> <4DFB6D53.1070401@go6.si> <474259A9-0A44-4D52-90A1-F218889B994A@cisco.com> <4DFDB5CC.3010709@go6.si> <8AFD9F5F-6FC9-4BAC-8736-7FFCC0E995F1@marcoh.net> <4DFDE62E.5070306@pragma.si> <00a101cc2f2f$5876f0a0$0964d1e0$@info> Message-ID: <4DFF1874.2030304@sweet-sorrow.com> 5:0 please! Us On 06/20/2011 11:49 AM, Ivan Pepelnjak wrote: > 4:0 for the short text. > >> -----Original Message----- >> From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of >> Jan Zorz >> Sent: Sunday, June 19, 2011 2:06 PM >> To: ipv6-wg at ripe.net >> Subject: Re: [ipv6-wg] New version (or followup) of RIPE-501 document... >> >> On 6/19/11 11:34 AM, Marco Hogewoning wrote: >>> On a personal note: I agree with Ole, it is redundant to split it all up >> and in the long run it could also lead to discrepancies between the two. >> Stick with referring to 6104 and be done with it. Questions or comments on >> the exact profile can be directed at the IETF, making it the same with the >> references to 3Gpp. >> Taken into account. >> >> 3:0 for short text. >> >> /jan > > From ip at ioshints.info Mon Jun 20 11:53:57 2011 From: ip at ioshints.info (Ivan Pepelnjak) Date: Mon, 20 Jun 2011 11:53:57 +0200 Subject: [ipv6-wg] New version (or followup) of RIPE-501 document... In-Reply-To: References: <4DECE2EC.8060600@go6.si> <26892F2C-E8DD-40E8-8F3F-E27E970A4A0A@marcoh.net> <4DF9BF44.2010706@go6.si> <4DFB43AE.1080006@otenet.gr> <4DFB6D53.1070401@go6.si> <474259A9-0A44-4D52-90A1-F218889B994A@cisco.com> <21D352FB-79DE-4426-B6C1-20D7C2235901@ecs.soton.ac.uk> Message-ID: <00a801cc2f2f$faf12da0$f0d388e0$@info> > I think load balancers should be included; I know some universities who > did not take part in W6D not because their web servers couldn't be made v6 > ready, but because their load balancers could not. ... and some of us had to deploy NAT-PT on an obsolete router just to make 6-to-4 transition before hitting the 6-unaware LBs. Nasty. Agreed - LBs should be made part of the document. > Switches: > - add RA-Guard (RFC 6105 I think) Agreed. Absolutely mandatory for any somewhat-secure deployment. > Firewalls: > - surprised SeND is optional How many people are deploying SeND? Even in DMZ? Ivan From tjc at ecs.soton.ac.uk Mon Jun 20 12:19:37 2011 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Mon, 20 Jun 2011 11:19:37 +0100 Subject: [ipv6-wg] New version (or followup) of RIPE-501 document... In-Reply-To: <00a801cc2f2f$faf12da0$f0d388e0$@info> References: <4DECE2EC.8060600@go6.si> <26892F2C-E8DD-40E8-8F3F-E27E970A4A0A@marcoh.net> <4DF9BF44.2010706@go6.si> <4DFB43AE.1080006@otenet.gr> <4DFB6D53.1070401@go6.si> <474259A9-0A44-4D52-90A1-F218889B994A@cisco.com> <21D352FB-79DE-4426-B6C1-20D7C2235901@ecs.soton.ac.uk> <00a801cc2f2f$faf12da0$f0d388e0$@info> <267EEBE3-AC8C-40D3-BC04-C6184F7E426E@ecs.soton.ac.uk> Message-ID: On 20 Jun 2011, at 10:53, Ivan Pepelnjak wrote: >> I think load balancers should be included; I know some universities who >> did not take part in W6D not because their web servers couldn't be made v6 >> ready, but because their load balancers could not. > > ... and some of us had to deploy NAT-PT on an obsolete router just to make 6-to-4 transition before hitting the 6-unaware LBs. Nasty. Well, if that was your option, maybe better to not take part. Though I hear a lot of sites did this. >> Firewalls: >> - surprised SeND is optional > > How many people are deploying SeND? Even in DMZ? Fair point. There are other ways to deploy a DMZ to help protect against the types of attack SeND can mitigate. Tim From kzorba at otenet.gr Mon Jun 20 14:07:31 2011 From: kzorba at otenet.gr (Kostas Zorbadelos) Date: Mon, 20 Jun 2011 15:07:31 +0300 Subject: [ipv6-wg] New version (or followup) of RIPE-501 document... In-Reply-To: References: <4DECE2EC.8060600@go6.si> <26892F2C-E8DD-40E8-8F3F-E27E970A4A0A@marcoh.net> <4DF9BF44.2010706@go6.si> <4DFB43AE.1080006@otenet.gr> <4DFB6D53.1070401@go6.si> <474259A9-0A44-4D52-90A1-F218889B994A@cisco.com> <21D352FB-79DE-4426-B6C1-20D7C2235901@ecs.soton.ac.uk> Message-ID: <4DFF3803.50509@otenet.gr> On 06/20/2011 12:40 PM, Tim Chown wrote: > I think load balancers should be included; I know some universities who did not take part in W6D not because their web servers couldn't be made v6 ready, but because their load balancers could not. Although the thread may deviate a bit, since we got into the topic of load balancers, does anyone have any pointers or references to work describing how load balancers can/should operate in an IPv6 environment? The reasons for asking are: - we need such references to include in RIPE-501 - in the IPv4 world a lot of the load balancing logic has to do with NAT. In IPv6, NAT should be a forbidden notion. Of course someone could just terminate connections and open new ones in backend farms of machines effectively acting as an application layer proxy. Regards, Kostas From ip at ioshints.info Mon Jun 20 14:30:34 2011 From: ip at ioshints.info (Ivan Pepelnjak) Date: Mon, 20 Jun 2011 14:30:34 +0200 Subject: [ipv6-wg] New version (or followup) of RIPE-501 document... In-Reply-To: <4DFF3803.50509@otenet.gr> References: <4DECE2EC.8060600@go6.si> <26892F2C-E8DD-40E8-8F3F-E27E970A4A0A@marcoh.net> <4DF9BF44.2010706@go6.si> <4DFB43AE.1080006@otenet.gr> <4DFB6D53.1070401@go6.si> <474259A9-0A44-4D52-90A1-F218889B994A@cisco.com> <21D352FB-79DE-4426-B6C1-20D7C2235901@ecs.soton.ac.uk> <4DFF3803.50509@otenet.gr> Message-ID: <00df01cc2f45$db7be300$9273a900$@info> > On 06/20/2011 12:40 PM, Tim Chown wrote: > > I think load balancers should be included; I know some universities who > did not take part in W6D not because their web servers couldn't be made v6 > ready, but because their load balancers could not. > > Although the thread may deviate a bit, since we got into the topic of > load balancers, does anyone have any pointers or references to work > describing how load balancers can/should operate in an IPv6 environment? > > The reasons for asking are: > > - we need such references to include in RIPE-501 > - in the IPv4 world a lot of the load balancing logic has to do > with NAT. In IPv6, NAT should be a forbidden notion. Of course someone > could just terminate connections and open new ones in backend farms of > machines effectively acting as an application layer proxy. Getting more and more off-topic, but regardless of what purists might think, load balancing is a crucial function (until TCP stack and/or socket API get fixed - read: not likely) and at least some of them do and will use some sort of NAT to do their job. Of course those vendors that can do high-speed TCP termination (sometimes even in hardware) will tell you why that's infinitely better ... and the purists will be happy because you've replaced abhorred NAT with oh-so-much-better TCP relay ;) Unfortunately, the net result is the same - loss of direct end-to-end client-to-server connectivity. Just my mildly sarcastic view of the NAT-in-LB topic Ivan From tjc at ecs.soton.ac.uk Mon Jun 20 14:43:05 2011 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Mon, 20 Jun 2011 13:43:05 +0100 Subject: [ipv6-wg] New version (or followup) of RIPE-501 document... In-Reply-To: <00df01cc2f45$db7be300$9273a900$@info> References: <4DECE2EC.8060600@go6.si> <26892F2C-E8DD-40E8-8F3F-E27E970A4A0A@marcoh.net> <4DF9BF44.2010706@go6.si> <4DFB43AE.1080006@otenet.gr> <4DFB6D53.1070401@go6.si> <474259A9-0A44-4D52-90A1-F218889B994A@cisco.com> <21D352FB-79DE-4426-B6C1-20D7C2235901@ecs.soton.ac.uk> <4DFF3803.50509@otenet.gr> <00df01cc2f45$db7be300$9273a900$@info> Message-ID: On 20 Jun 2011, at 13:30, Ivan Pepelnjak wrote: > > Getting more and more off-topic, but regardless of what purists might think, load balancing is a crucial function (until TCP stack and/or socket API get fixed - read: not likely) and at least some of them do and will use some sort of NAT to do their job. I think this is the key point. While providers are not putting up content on IPv6 for this reason, it is an issue. Tim From ip at ioshints.info Mon Jun 20 15:37:23 2011 From: ip at ioshints.info (Ivan Pepelnjak) Date: Mon, 20 Jun 2011 15:37:23 +0200 Subject: [ipv6-wg] New version (or followup) of RIPE-501 document... In-Reply-To: References: <4DECE2EC.8060600@go6.si> <26892F2C-E8DD-40E8-8F3F-E27E970A4A0A@marcoh.net> <4DF9BF44.2010706@go6.si> <4DFB43AE.1080006@otenet.gr> <4DFB6D53.1070401@go6.si> <474259A9-0A44-4D52-90A1-F218889B994A@cisco.com> <21D352FB-79DE-4426-B6C1-20D7C2235901@ecs.soton.ac.uk> <4DFF3803.50509@otenet.gr> <00df01cc2f45$db7be300$9273a900$@info> Message-ID: <00f801cc2f4f$316423f0$942c6bd0$@info> Lack of IPv6 support in some LB products has nothing to do with orthodox beliefs in purity of NAT-less IPv6 world and all to do with the vendors' decisions to cut hardware costs by supporting only 32-bit addresses in their hardware implementation (if you have a software-only LB that still doesn't support IPv6 today, please let me know ;). And of course some of us were stupid enough (or trusting the vendor, which is the same thing) not to check whether the appliance we bought a few years ago will ever support IPv6. Ivan > > Getting more and more off-topic, but regardless of what purists might > think, load balancing is a crucial function (until TCP stack and/or socket > API get fixed - read: not likely) and at least some of them do and will > use some sort of NAT to do their job. > > I think this is the key point. While providers are not putting up content > on IPv6 for this reason, it is an issue. > > Tim From jan at go6.si Mon Jun 20 18:33:23 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Mon, 20 Jun 2011 18:33:23 +0200 Subject: [ipv6-wg] New version (or followup) of RIPE-501 document... In-Reply-To: <00f801cc2f4f$316423f0$942c6bd0$@info> References: <4DECE2EC.8060600@go6.si> <26892F2C-E8DD-40E8-8F3F-E27E970A4A0A@marcoh.net> <4DF9BF44.2010706@go6.si> <4DFB43AE.1080006@otenet.gr> <4DFB6D53.1070401@go6.si> <474259A9-0A44-4D52-90A1-F218889B994A@cisco.com> <21D352FB-79DE-4426-B6C1-20D7C2235901@ecs.soton.ac.uk> <4DFF3803.50509@otenet.gr> <00df01cc2f45$db7be300$9273a900$@info> <00f801cc2f4f$316423f0$942c6bd0$@info> Message-ID: <4DFF7653.4040706@go6.si> >>> Getting more and more off-topic, but regardless of what purists might >> think, load balancing is a crucial function (until TCP stack and/or socket >> API get fixed - read: not likely) and at least some of them do and will >> use some sort of NAT to do their job. >> >> I think this is the key point. While providers are not putting up content >> on IPv6 for this reason, it is an issue. Ok, so I see some consensus on the question, if load balancers are needed in RIPE-501 foloowup document or not. The answer is yes. My question is, should we create new hw category for this or should we put it in any of existing category? Merike, Sander, I'm inviting you back to drawing board to fix this request :) /jan From ip at ioshints.info Mon Jun 20 19:00:22 2011 From: ip at ioshints.info (Ivan Pepelnjak) Date: Mon, 20 Jun 2011 19:00:22 +0200 Subject: [ipv6-wg] New version (or followup) of RIPE-501 document... In-Reply-To: <4DFF7653.4040706@go6.si> References: <4DECE2EC.8060600@go6.si> <26892F2C-E8DD-40E8-8F3F-E27E970A4A0A@marcoh.net> <4DF9BF44.2010706@go6.si> <4DFB43AE.1080006@otenet.gr> <4DFB6D53.1070401@go6.si> <474259A9-0A44-4D52-90A1-F218889B994A@cisco.com> <21D352FB-79DE-4426-B6C1-20D7C2235901@ecs.soton.ac.uk> <4DFF3803.50509@otenet.gr> <00df01cc2f45$db7be300$9273a900$@info> <00f801cc2f4f$316423f0$942c6bd0$@info> <4DFF7653.4040706@go6.si> Message-ID: <003001cc2f6b$8cb09290$a611b7b0$@info> The minimum you need for load balancers is IPv6 host support, you might add OPTIONAL support for routing protocols. Obviously they need to support 6-to-4 and 6-to-6 load balancing ... are there any RFCs covering those? Ivan > -----Original Message----- > From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of > Jan Zorz @ go6.si > Sent: Monday, June 20, 2011 6:33 PM > To: ipv6-wg at ripe.net > Subject: Re: [ipv6-wg] New version (or followup) of RIPE-501 document... > > > >>> Getting more and more off-topic, but regardless of what purists might > >> think, load balancing is a crucial function (until TCP stack and/or > socket > >> API get fixed - read: not likely) and at least some of them do and will > >> use some sort of NAT to do their job. > >> > >> I think this is the key point. While providers are not putting up > content > >> on IPv6 for this reason, it is an issue. > > Ok, so I see some consensus on the question, if load balancers are > needed in RIPE-501 foloowup document or not. The answer is yes. > > My question is, should we create new hw category for this or should we > put it in any of existing category? > > Merike, Sander, I'm inviting you back to drawing board to fix this > request :) > > /jan From kzorba at otenet.gr Mon Jun 20 20:34:04 2011 From: kzorba at otenet.gr (kzorba at otenet.gr) Date: Mon, 20 Jun 2011 21:34:04 +0300 Subject: [ipv6-wg] New version (or followup) of RIPE-501 document... In-Reply-To: <003001cc2f6b$8cb09290$a611b7b0$@info> References: <4DECE2EC.8060600@go6.si> <26892F2C-E8DD-40E8-8F3F-E27E970A4A0A@marcoh.net> <4DF9BF44.2010706@go6.si> <4DFB43AE.1080006@otenet.gr> <4DFB6D53.1070401@go6.si> <474259A9-0A44-4D52-90A1-F218889B994A@cisco.com> <21D352FB-79DE-4426-B6C1-20D7C2235901@ecs.soton.ac.uk> <4DFF3803.50509@otenet.gr> <00df01cc2f45$db7be300$9273a900$@info> <00f801cc2f4f$316423f0$942c6bd0$@info> <4DFF7653.4040706@go6.si> <003001cc2f6b$8cb09290$a611b7b0$@info> Message-ID: <20110620213404.20896fsdddn98exo@noc.otenet.gr> Quoting Ivan Pepelnjak : > The minimum you need for load balancers is IPv6 host support, you > might add OPTIONAL support for routing protocols. > > Obviously they need to support 6-to-4 and 6-to-6 load balancing ... > are there any RFCs covering those? > This is indeed the question. Is there any work (in IETF probably) that describes what a load balancer is and what it should support in an IPv6 environment? If not I think we need to improvise. I also think that load balancing is crucial to the deployment not only for IPv6 content but any IPv6 service that needs to scale. Kostas > Ivan > From sander at steffann.nl Mon Jun 20 21:38:28 2011 From: sander at steffann.nl (Sander Steffann) Date: Mon, 20 Jun 2011 21:38:28 +0200 Subject: [ipv6-wg] New version (or followup) of RIPE-501 document... In-Reply-To: <4DFF7653.4040706@go6.si> References: <4DECE2EC.8060600@go6.si> <26892F2C-E8DD-40E8-8F3F-E27E970A4A0A@marcoh.net> <4DF9BF44.2010706@go6.si> <4DFB43AE.1080006@otenet.gr> <4DFB6D53.1070401@go6.si> <474259A9-0A44-4D52-90A1-F218889B994A@cisco.com> <21D352FB-79DE-4426-B6C1-20D7C2235901@ecs.soton.ac.uk> <4DFF3803.50509@otenet.gr> <00df01cc2f45$db7be300$9273a900$@info> <00f801cc2f4f$316423f0$942c6bd0$@info> <4DFF7653.4040706@go6.si> Message-ID: <2B694BEC-1F21-4609-8FBF-DA84A8BEC711@steffann.nl> Hi, >>>> Getting more and more off-topic, but regardless of what purists might >>> think, load balancing is a crucial function (until TCP stack and/or socket >>> API get fixed - read: not likely) and at least some of them do and will >>> use some sort of NAT to do their job. >>> >>> I think this is the key point. While providers are not putting up content >>> on IPv6 for this reason, it is an issue. > > Ok, so I see some consensus on the question, if load balancers are needed in RIPE-501 foloowup document or not. The answer is yes. > > My question is, should we create new hw category for this or should we put it in any of existing category? > > Merike, Sander, I'm inviting you back to drawing board to fix this request :) Invitation accepted :-) The difficult bit is defining 'load balancer'... There are so many different ways to implement this, at different layers. I have seen layer-7 proxy based load balancers, but also layer-3 direct-routing ones, with other options in between. Some look like a client to the back end servers, but others need cooperation from those servers. The sum of load balancers and back end servers have to look like an end-node to the outside world, but inside anything (well, almost) is possible. So, can we compile a list of load balancing methods and can we specify what is needed for each method? Do we want to do this? Or can we say 'the server farm as a whole needs to behave like an end-node'? But I fully agree: we need to say *something* about load balancers! Sander From jonas.lindkvist at trafikverket.se Mon Jun 20 22:01:55 2011 From: jonas.lindkvist at trafikverket.se (jonas.lindkvist at trafikverket.se) Date: Mon, 20 Jun 2011 20:01:55 +0000 Subject: SV: [ipv6-wg] New version (or followup) of RIPE-501 document... In-Reply-To: <2B694BEC-1F21-4609-8FBF-DA84A8BEC711@steffann.nl> References: <4DECE2EC.8060600@go6.si> <26892F2C-E8DD-40E8-8F3F-E27E970A4A0A@marcoh.net> <4DF9BF44.2010706@go6.si> <4DFB43AE.1080006@otenet.gr> <4DFB6D53.1070401@go6.si> <474259A9-0A44-4D52-90A1-F218889B994A@cisco.com> <21D352FB-79DE-4426-B6C1-20D7C2235901@ecs.soton.ac.uk> <4DFF3803.50509@otenet.gr> <00df01cc2f45$db7be300$9273a900$@info> <00f801cc2f4f$316423f0$942c6bd0$@info> <4DFF7653.4040706@go6.si> <2B694BEC-1F21-4609-8FBF-DA84A8BEC711@steffann.nl> Message-ID: <40240E536233394382F4D5205BF761C723CB832E@TRV0272.trafikverket.local> Hi, A loadbalancer is a loadbalancer is a loadbalancer..... It should perform the same function in v6 as in in v4. So is there a definition on loadbalancers in general? Do we need to define what layer it?s working on? Regards Jonas >-----Ursprungligt meddelande----- >Fr?n: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] F?r Sander >Steffann >Skickat: den 20 juni 2011 21:38 >Till: Jan Zorz@ >Kopia: ipv6-wg at ripe.net >?mne: Re: [ipv6-wg] New version (or followup) of RIPE-501 document... > >Hi, > >>>>> Getting more and more off-topic, but regardless of what purists >might >>>> think, load balancing is a crucial function (until TCP stack and/or >socket >>>> API get fixed - read: not likely) and at least some of them do and >will >>>> use some sort of NAT to do their job. >>>> >>>> I think this is the key point. While providers are not putting up >content >>>> on IPv6 for this reason, it is an issue. >> >> Ok, so I see some consensus on the question, if load balancers are >needed in RIPE-501 foloowup document or not. The answer is yes. >> >> My question is, should we create new hw category for this or should we >put it in any of existing category? >> >> Merike, Sander, I'm inviting you back to drawing board to fix this >request :) > >Invitation accepted :-) > >The difficult bit is defining 'load balancer'... There are so many >different ways to implement this, at different layers. I have seen >layer-7 proxy based load balancers, but also layer-3 direct-routing >ones, with other options in between. Some look like a client to the back >end servers, but others need cooperation from those servers. The sum of >load balancers and back end servers have to look like an end-node to the >outside world, but inside anything (well, almost) is possible. > >So, can we compile a list of load balancing methods and can we specify >what is needed for each method? Do we want to do this? Or can we say >'the server farm as a whole needs to behave like an end-node'? > >But I fully agree: we need to say *something* about load balancers! >Sander From sander at steffann.nl Mon Jun 20 22:51:03 2011 From: sander at steffann.nl (Sander Steffann) Date: Mon, 20 Jun 2011 22:51:03 +0200 Subject: SV: [ipv6-wg] New version (or followup) of RIPE-501 document... In-Reply-To: <40240E536233394382F4D5205BF761C723CB832E@TRV0272.trafikverket.local> References: <4DECE2EC.8060600@go6.si> <26892F2C-E8DD-40E8-8F3F-E27E970A4A0A@marcoh.net> <4DF9BF44.2010706@go6.si> <4DFB43AE.1080006@otenet.gr> <4DFB6D53.1070401@go6.si> <474259A9-0A44-4D52-90A1-F218889B994A@cisco.com> <21D352FB-79DE-4426-B6C1-20D7C2235901@ecs.soton.ac.uk> <4DFF3803.50509@otenet.gr> <00df01cc2f45$db7be300$9273a900$@info> <00f801cc2f4f$316423f0$942c6bd0$@info> <4DFF7653.4040706@go6.si> <2B694BEC-1F21-4609-8FBF-DA84A8BEC711@steffann.nl> <40240E536233394382F4D5205BF761C723CB832E@TRV0272.trafikverket.local> Message-ID: Hi, > A loadbalancer is a loadbalancer is a loadbalancer..... > It should perform the same function in v6 as in in v4. So is there > a definition on loadbalancers in general? Do we need to define > what layer it?s working on? I don't know... We might. If we are going to provide guidelines for tender initiators for buying load balancers, what useful guidelines can we provide? We provide a list of mandatory and optional RFCs for the other equipment, so which RFCs does a load balancer need to support? - Sander From ip at ioshints.info Tue Jun 21 08:08:02 2011 From: ip at ioshints.info (Ivan Pepelnjak) Date: Tue, 21 Jun 2011 08:08:02 +0200 Subject: [ipv6-wg] New version (or followup) of RIPE-501 document... In-Reply-To: <2B694BEC-1F21-4609-8FBF-DA84A8BEC711@steffann.nl> References: <4DECE2EC.8060600@go6.si> <26892F2C-E8DD-40E8-8F3F-E27E970A4A0A@marcoh.net> <4DF9BF44.2010706@go6.si> <4DFB43AE.1080006@otenet.gr> <4DFB6D53.1070401@go6.si> <474259A9-0A44-4D52-90A1-F218889B994A@cisco.com> <21D352FB-79DE-4426-B6C1-20D7C2235901@ecs.soton.ac.uk> <4DFF3803.50509@otenet.gr> <00df01cc2f45$db7be300$9273a900$@info> <00f801cc2f4f$316423f0$942c6bd0$@info> <4DFF7653.4040706@go6.si> <2B694BEC-1F21-4609-8FBF-DA84A8BEC711@steffann.nl> Message-ID: <007301cc2fd9$95f630d0$c1e29270$@info> >From the "outside" perspective, a load-balanced service implemented with one or more redundant load balancers _MUST_ look like an IPv4 _OR_ an IPv6 address (where OR is not exclusive, but AND is not strictly necessary) distributing sessions to IPv4 or IPv6 inside nodes. It _SHOULD_ be able distribute sessions arriving to an outside address (IPv4 or IPv6) to a mixed cluster of IPv4 _AND_ IPv6 addresses. How a LB device implements its magic (L4 passthrough with NAT, L4 termination, L7 proxy, whatever other tricks) is irrelevant (and seems there are no "obvious" RFCs documenting it). What is MANDATORY is that it supports connections from IPv6 clients to IPv4 and/or IPv6 servers and from IPv4 clients to IPv4 and/or IPv6 servers (see last sentence in the previous paragraph) to enable all possible migration scenarios. However, I would recommend that for 6-to-4 functionality, we _RECOMMEND_ the load balancer adheres to the RFC6146 (stateful NAT64) - we should discourage (but not forbid) vendors from doing homebrew 6-to-4 translation when a standard exists specifying how to do it. On the IPv6 protocol side, the very minimum requirement is adherence to IPv6 host behavior. Some LB designs work without significant support for routing - single inside and outside /64 with RA-generated default route on the outside - or they could support some routing protocols. Those should (in my opinion) be made _OPTIONAL_. Oh, and I never claimed I know anything about load balancers, so I might be totally wrong ;) Ivan > -----Original Message----- > From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of > Sander Steffann > Sent: Monday, June 20, 2011 9:38 PM > To: Jan Zorz @ go6.si > Cc: ipv6-wg at ripe.net > Subject: Re: [ipv6-wg] New version (or followup) of RIPE-501 document... > > Hi, > > >>>> Getting more and more off-topic, but regardless of what purists might > >>> think, load balancing is a crucial function (until TCP stack and/or > socket > >>> API get fixed - read: not likely) and at least some of them do and > will > >>> use some sort of NAT to do their job. > >>> > >>> I think this is the key point. While providers are not putting up > content > >>> on IPv6 for this reason, it is an issue. > > > > Ok, so I see some consensus on the question, if load balancers are > needed in RIPE-501 foloowup document or not. The answer is yes. > > > > My question is, should we create new hw category for this or should we > put it in any of existing category? > > > > Merike, Sander, I'm inviting you back to drawing board to fix this > request :) > > Invitation accepted :-) > > The difficult bit is defining 'load balancer'... There are so many > different ways to implement this, at different layers. I have seen layer-7 > proxy based load balancers, but also layer-3 direct-routing ones, with > other options in between. Some look like a client to the back end servers, > but others need cooperation from those servers. The sum of load balancers > and back end servers have to look like an end-node to the outside world, > but inside anything (well, almost) is possible. > > So, can we compile a list of load balancing methods and can we specify > what is needed for each method? Do we want to do this? Or can we say 'the > server farm as a whole needs to behave like an end-node'? > > But I fully agree: we need to say *something* about load balancers! > Sander From sander at steffann.nl Tue Jun 21 08:22:38 2011 From: sander at steffann.nl (Sander Steffann) Date: Tue, 21 Jun 2011 08:22:38 +0200 Subject: [ipv6-wg] New version (or followup) of RIPE-501 document... In-Reply-To: <007301cc2fd9$95f630d0$c1e29270$@info> References: <4DECE2EC.8060600@go6.si> <26892F2C-E8DD-40E8-8F3F-E27E970A4A0A@marcoh.net> <4DF9BF44.2010706@go6.si> <4DFB43AE.1080006@otenet.gr> <4DFB6D53.1070401@go6.si> <474259A9-0A44-4D52-90A1-F218889B994A@cisco.com> <21D352FB-79DE-4426-B6C1-20D7C2235901@ecs.soton.ac.uk> <4DFF3803.50509@otenet.gr> <00df01cc2f45$db7be300$9273a900$@info> <00f801cc2f4f$316423f0$942c6bd0$@info> <4DFF7653.4040706@go6.si> <2B694BEC-1F21-4609-8FBF-DA84A8BEC711@steffann.nl> <007301cc2fd9$95f630d0$c1e29270$@info> Message-ID: <61454080-AC6F-4D8D-8912-4D4E466DFA62@steffann.nl> Hi, > [...] > > Oh, and I never claimed I know anything about load balancers, so I might be totally wrong ;) It seems to be useful input, so thank you anyway ;-) Sander From kzorba at otenet.gr Tue Jun 21 08:42:23 2011 From: kzorba at otenet.gr (Kostas Zorbadelos) Date: Tue, 21 Jun 2011 09:42:23 +0300 Subject: [ipv6-wg] New version (or followup) of RIPE-501 document... In-Reply-To: <007301cc2fd9$95f630d0$c1e29270$@info> References: <4DECE2EC.8060600@go6.si> <26892F2C-E8DD-40E8-8F3F-E27E970A4A0A@marcoh.net> <4DF9BF44.2010706@go6.si> <4DFB43AE.1080006@otenet.gr> <4DFB6D53.1070401@go6.si> <474259A9-0A44-4D52-90A1-F218889B994A@cisco.com> <21D352FB-79DE-4426-B6C1-20D7C2235901@ecs.soton.ac.uk> <4DFF3803.50509@otenet.gr> <00df01cc2f45$db7be300$9273a900$@info> <00f801cc2f4f$316423f0$942c6bd0$@info> <4DFF7653.4040706@go6.si> <2B694BEC-1F21-4609-8FBF-DA84A8BEC711@steffann.nl> <007301cc2fd9$95f630d0$c1e29270$@info> Message-ID: <4E003D4F.3080505@otenet.gr> On 06/21/2011 09:08 AM, Ivan Pepelnjak wrote: I also do not claim to be any kind of expert, I am just interested in the load balancing subject ;-) First of all, I must say that I am on the purist side. I don't like NAT and I am a bit skeptic about employing NAT for load balancing even in the IPv4 world. Having said that, our current production setup relies heavily on load balancers doing NAT in their internal workings. There must be better ways to address the problem in an IPv6 environment with L4 termination or L7 application layer proxies coming to mind. For me however, for a load balanced service, the requirement is one name in the DNS and not a single IP (v4 or v6) address. I can understand that it is a very wide subject and I don't have an answer of how to address it in a document like RIPE 501. Regards, Kostas > From the "outside" perspective, a load-balanced service implemented with one or more redundant load balancers _MUST_ look like an IPv4 _OR_ an IPv6 address (where OR is not exclusive, but AND is not strictly necessary) distributing sessions to IPv4 or IPv6 inside nodes. It _SHOULD_ be able distribute sessions arriving to an outside address (IPv4 or IPv6) to a mixed cluster of IPv4 _AND_ IPv6 addresses. > > How a LB device implements its magic (L4 passthrough with NAT, L4 termination, L7 proxy, whatever other tricks) is irrelevant (and seems there are no "obvious" RFCs documenting it). What is MANDATORY is that it supports connections from IPv6 clients to IPv4 and/or IPv6 servers and from IPv4 clients to IPv4 and/or IPv6 servers (see last sentence in the previous paragraph) to enable all possible migration scenarios. > > However, I would recommend that for 6-to-4 functionality, we _RECOMMEND_ the load balancer adheres to the RFC6146 (stateful NAT64) - we should discourage (but not forbid) vendors from doing homebrew 6-to-4 translation when a standard exists specifying how to do it. > > On the IPv6 protocol side, the very minimum requirement is adherence to IPv6 host behavior. Some LB designs work without significant support for routing - single inside and outside /64 with RA-generated default route on the outside - or they could support some routing protocols. Those should (in my opinion) be made _OPTIONAL_. > > Oh, and I never claimed I know anything about load balancers, so I might be totally wrong ;) > Ivan > >> -----Original Message----- >> From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of >> Sander Steffann >> Sent: Monday, June 20, 2011 9:38 PM >> To: Jan Zorz @ go6.si >> Cc: ipv6-wg at ripe.net >> Subject: Re: [ipv6-wg] New version (or followup) of RIPE-501 document... >> >> Hi, >> >>>>>> Getting more and more off-topic, but regardless of what purists might >>>>> think, load balancing is a crucial function (until TCP stack and/or >> socket >>>>> API get fixed - read: not likely) and at least some of them do and >> will >>>>> use some sort of NAT to do their job. >>>>> >>>>> I think this is the key point. While providers are not putting up >> content >>>>> on IPv6 for this reason, it is an issue. >>> >>> Ok, so I see some consensus on the question, if load balancers are >> needed in RIPE-501 foloowup document or not. The answer is yes. >>> >>> My question is, should we create new hw category for this or should we >> put it in any of existing category? >>> >>> Merike, Sander, I'm inviting you back to drawing board to fix this >> request :) >> >> Invitation accepted :-) >> >> The difficult bit is defining 'load balancer'... There are so many >> different ways to implement this, at different layers. I have seen layer-7 >> proxy based load balancers, but also layer-3 direct-routing ones, with >> other options in between. Some look like a client to the back end servers, >> but others need cooperation from those servers. The sum of load balancers >> and back end servers have to look like an end-node to the outside world, >> but inside anything (well, almost) is possible. >> >> So, can we compile a list of load balancing methods and can we specify >> what is needed for each method? Do we want to do this? Or can we say 'the >> server farm as a whole needs to behave like an end-node'? >> >> But I fully agree: we need to say *something* about load balancers! >> Sander > From ip at ioshints.info Tue Jun 21 09:34:01 2011 From: ip at ioshints.info (Ivan Pepelnjak) Date: Tue, 21 Jun 2011 09:34:01 +0200 Subject: [ipv6-wg] New version (or followup) of RIPE-501 document... In-Reply-To: <4E003D4F.3080505@otenet.gr> References: <4DECE2EC.8060600@go6.si> <26892F2C-E8DD-40E8-8F3F-E27E970A4A0A@marcoh.net> <4DF9BF44.2010706@go6.si> <4DFB43AE.1080006@otenet.gr> <4DFB6D53.1070401@go6.si> <474259A9-0A44-4D52-90A1-F218889B994A@cisco.com> <21D352FB-79DE-4426-B6C1-20D7C2235901@ecs.soton.ac.uk> <4DFF3803.50509@otenet.gr> <00df01cc2f45$db7be300$9273a900$@info> <00f801cc2f4f$316423f0$942c6bd0$@info> <4DFF7653.4040706@go6.si> <2B694BEC-1F21-4609-8FBF-DA84A8BEC711@steffann.nl> <007301cc2fd9$95f630d0$c1e29270$@info> <4E003D4F.3080505@otenet.gr> Message-ID: <009f01cc2fe5$98ebaca0$cac305e0$@info> > There must be better ways to address the problem in an IPv6 environment > with L4 termination or L7 application layer proxies coming to mind. I guess not many ops-focused people have the luxury to care. Regardless of how you do it, you lose end-to-end connectivity and some visibility (the latter is BTW mandated by some standards like PCI). > For me however, for a load balanced service, the requirement is one name in > the DNS and not a single IP (v4 or v6) address. In a perfect world with perfectly architected and implemented TCP stacks and no security issues mandating browser DNS pinning, you're absolutely correct. In the imperfect world we have to live in, you usually stop fighting the windmills and use a single IP address if you have to get enough nines. Ivan From jan at go6.si Tue Jun 21 09:53:58 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Tue, 21 Jun 2011 09:53:58 +0200 Subject: [ipv6-wg] New version (or followup) of RIPE-501 document... In-Reply-To: <009f01cc2fe5$98ebaca0$cac305e0$@info> References: <4DECE2EC.8060600@go6.si> <26892F2C-E8DD-40E8-8F3F-E27E970A4A0A@marcoh.net> <4DF9BF44.2010706@go6.si> <4DFB43AE.1080006@otenet.gr> <4DFB6D53.1070401@go6.si> <474259A9-0A44-4D52-90A1-F218889B994A@cisco.com> <21D352FB-79DE-4426-B6C1-20D7C2235901@ecs.soton.ac.uk> <4DFF3803.50509@otenet.gr> <00df01cc2f45$db7be300$9273a900$@info> <00f801cc2f4f$316423f0$942c6bd0$@info> <4DFF7653.4040706@go6.si> <2B694BEC-1F21-4609-8FBF-DA84A8BEC711@steffann.nl> <007301cc2fd9$95f630d0$c1e29270$@info> <4E003D4F.3080505@otenet.gr> <009f01cc2fe5$98ebaca0$cac305e0$@info> Message-ID: <4E004E16.5000409@go6.si> On 6/21/11 9:34 AM, Ivan Pepelnjak wrote: >> There must be better ways to address the problem in an IPv6 >> environment with L4 termination or L7 application layer proxies >> coming to mind. > > I guess not many ops-focused people have the luxury to care. > Regardless of how you do it, you lose end-to-end connectivity and > some visibility (the latter is BTW mandated by some standards like > PCI). > >> For me however, for a load balanced service, the requirement is one >> name in the DNS and not a single IP (v4 or v6) address. > > In a perfect world with perfectly architected and implemented TCP > stacks and no security issues mandating browser DNS pinning, you're > absolutely correct. > > In the imperfect world we have to live in, you usually stop fighting > the windmills and use a single IP address if you have to get enough > nines. > > Ivan > Pragatism as paradigm. I like that. BTW, do we have any LB vendor on the list with some useful suggestion? Cheers, /jan From shane at time-travellers.org Tue Jun 21 11:58:33 2011 From: shane at time-travellers.org (Shane Kerr) Date: Tue, 21 Jun 2011 11:58:33 +0200 Subject: [ipv6-wg] IETF working group on renumbering in IPv6 Message-ID: <1308650313.3570.19.camel@shane-desktop> All, There is some idea to work on the renumbering problem in IPv6. This is certainly of interest to IPv6 folks, but I am including the address policy folks as this may ultimately have impact there. Cheers, -- Shane -------------- next part -------------- An embedded message was scrubbed... From: IESG Secretary Subject: WG Review: IPv6 Site Renumbering (6renum) Date: Thu, 2 Jun 2011 10:54:54 -0700 (PDT) Size: 9592 URL: From cris.pascual.gonzalez at gmail.com Thu Jun 23 04:01:29 2011 From: cris.pascual.gonzalez at gmail.com (Cristina Pascual) Date: Thu, 23 Jun 2011 04:01:29 +0200 Subject: [ipv6-wg] Last 10 Days: EMERGING 2011 || November 20-25, 2011 - Lisbon, Portugal Message-ID: <201106230201.p5N21T7u025581@smtp.upv.es> INVITATION: ================= Note that the submission deadline has been extended to July 1st, 2011. Please consider to contribute to and/or forward to the appropriate groups the following opportunity to submit and publish original scientific results. In addition, authors of selected papers will be invited to submit extended article versions to one of the IARIA Journals: http://www.iariajournals.org ================= ============== EMERGING 2011 | Call for Papers =============== CALL FOR PAPERS, TUTORIALS, PANELS EMERGING 2011: The Third International Conference on Emerging Network Intelligence November 20-25, 2011 - Lisbon, Portugal General page: http://www.iaria.org/conferences2011/EMERGING11.html Call for Papers: http://www.iaria.org/conferences2011/CfPEMERGING11.html - regular papers - short papers (work in progress) - industrial presentations - posters - ideas Submission page: http://www.iaria.org/conferences2011/SubmitEMERGING11.html Submission deadline: July 1st, 2011 Sponsored by IARIA, www.iaria.org Extended versions of selected papers will be published in IARIA Journals: http://www.iariajournals.org Please note the Poster Forum and Work in Progress options. The topics suggested by the conference can be discussed in term of concepts, state of the art, research, standards, implementations, running experiments, applications, and industrial case studies. Authors are invited to submit complete unpublished papers, which are not under review in any other conference or journal in the following, but not limited to, topic areas. All tracks are open to both research and industry contributions, in terms of Regular papers, Posters, Work in progress, Technical/marketing/business presentations, Demos, Tutorials, and Panels. Before submission, please check and comply with the Editorial rules: http://www.iaria.org/editorialrules.html EMERGING 2011 Topics (topics and submission details: see CfP on the site) Evolution of telecommunications network architectures Advanced communications systems; New configurable protocols stacks and real-time mechanisms; Applications and services for next-generation architectures; Scalability and manageability of network architectures; Opportunistic and cooperative communications; Next generation networks (NGN); Optical networks; Wireless networks, Mobile networks; Ad-Hoc, Sensor, Vehicle networks; Access, Residential, Last mile networks; Home, Body and Personal area Networks; Active networks; Self Organizing networks; Storage area networks; Peer-to-Peer and overlay networks; Network measurements and testbeds; Transmission technologies (e.g., Ultra Wideband) Applications and services Peer-to-Peer applications and services; Web services; Mobile applications; Entertainment and games; Home automation; Surveillance, Home monitoring; Medical and health applications; e-commerce, m-commerce; Location-based services; Real-time and multimedia applications; Real-time services over IP Networking and service differentiation Network design and planning; Network management and control; Traffic engineering; Traffic control, Flow control; Congestion and admission control; QoS support and Performance; Routing, Switching, QoS routing; Mobility management; Multicast; Service reliability, availability Emerging networking Network coding; Visualization of network behavior; Semantic routing; Network flow processing; Cross-layer design and optimization; High-speed networking; Context-aware mobile networking Advanced network elements Network processors; Content addressable memories; Multi-core processors; Context-aware reconfigurable devices; Portable and wearable devices; Mobile multimedia devices Optimization Power optimization in data centers; Delay and fault tolerant networks; Video conferencing and telepresence systems; Resource optimization; Context-aware optimization Quality Quality of service; Quality of performance; Quality of experience; Quality of data; Quality of modeling; Quality-oriented routing; Quality of context /degradation, trust, uncertainty, consistency/ Smartness Cognitive radio; Autonomic and dependable communications; Ambient systems; Identity and location in mobile environments; Smart homes; Brain-like networking and computing Discovery Resource discovery; Service discovery; Content discovery; Flaws/anomaly discovery Protection Anticipative control and management; Data protection strategies; Collaborative Internet attack containment; Micro-kernels and robustness Security Trust and credential negotiations; Privacy; Intrusion prevention and containment; Security in virtualization approach; Architectural support for security; Security, privacy, and dependability; Security in cooperative networks Programmability Programmable and real-time network traffic measurements; Adaptive scheduling; Network and application load balancing; High-performance capabilities-based networks; Software techniques to improve virtualized I/O performance End-user Frequently changing user profile; User mobility and ubiquity; Scalable and resource intensive multi-user distributed applications; User identity and multi-service access technologies; End-user perception; End-user based networking and service orchestration; End-user activity recognition with multiple goals Mobility Mobile Internet services; Mobility-oriented protocols /Mobile IP, etc./; Wearable and/or mobile technologies; Self-discovery and localizing entities; Seamless handover Ubiquity Ubiquitous computing; Pervasive and embedded systems; Ubiquitous sustainability; Sensing location; Activity patterns; Smart environments in the workplaces; Ubiquitous cities Semantics and Adaptiveness Content-aware networks; Network-aware applications; Semantic Web; Adaptive systems; Adaptive applications; Self-adaptiveness; Ontology-based adaptation; Semantic profile; Semantic service orchestration; Multi-technology semantic integration /sensors, ehealth, geosensing, etc./ Wireless Wireless access technologies / WLANs, WiMAX, satellite, 3G, etc./; Multi-hop wireless networks /sensor, ad hoc, mesh, etc./; Wireless QoS and reliability; Wireless body area networks; Energy optimization Emerging technologies and applications Vehicular ad hoc networks; Bio-inspired networks; Tele-medicine/e-health networks; User-centric services and applications; Autonomous and autonomic systems; Self-manageable systems; Emerging computation business models; Social networks; eSociety --------------- EMERGING Advisory Chairs Raj Jain, Washington University in St. Louis, USA Michael D. Logothetis, University of Patras, Greece Tulin Atmaca, IT/Telecom&Management SudParis, France Phuoc Tran-Gia, University of Wuerzburg, Germany Nuno M. Garcia, Universidade Lus?fonas de Humanidades e Tecnologias, Lisboa, Portugal EMERGING 2011 Industry Liaison Chairs Krishna Murthy, Quintiles, USA Tadashi Araragi, Nippon Telegraph and Telephone Corporation ? Kyoto, Japan Robert Foster, Edgemount Solutions - Plano, USA EMERGING 2011 Research Chair David Carrera, Barcelona Supercomputing Center (BSC) / Universitat Politecnica de Catalunya (UPC), Spain Committee: http://www.iaria.org/conferences2011/ComEMERGING11.html ==================== From cris.pascual.gonzalez at gmail.com Thu Jun 23 04:52:04 2011 From: cris.pascual.gonzalez at gmail.com (Cristina Pascual) Date: Thu, 23 Jun 2011 04:52:04 +0200 Subject: [ipv6-wg] Last 10 Days!: AP2PS 2011 || November 20-25, 2011 - Lisbon, Portugal Message-ID: <201106230252.p5N2q311004586@smtp.upv.es> INVITATION: ================= Note that the submission deadline has been extended to July 1st, 2011. Please consider to contribute to and/or forward to the appropriate groups the following opportunity to submit and publish original scientific results. In addition, authors of selected papers will be invited to submit extended article versions to one of the IARIA Journals: http://www.iariajournals.org ================= ============== AP2PS 2011 | Call for Papers =============== CALL FOR PAPERS, TUTORIALS, PANELS AP2PS 2011: The Third International Conference on Advances in P2P Systems November 20-25, 2011 - Lisbon, Portugal General page: http://www.iaria.org/conferences2011/AP2PS11.html Call for Papers: http://www.iaria.org/conferences2011/CfPAP2PS11.html - regular papers - short papers (work in progress) - industrial presentations - posters - ideas Submission page: http://www.iaria.org/conferences2011/SubmitAP2PS11.html Submission deadline: July 1st, 2011 Sponsored by IARIA, www.iaria.org Extended versions of selected papers will be published in IARIA Journals: http://www.iariajournals.org Please note the Poster Forum and Work in Progress (short papers) options. The topics suggested by the conference can be discussed in term of concepts, state of the art, research, standards, implementations, running experiments, applications, and industrial case studies. Authors are invited to submit complete unpublished papers, which are not under review in any other conference or journal in the following, but not limited to, topic areas. All tracks are open to both research and industry contributions, in terms of Regular papers, Posters, Work in progress, Technical/marketing/business presentations, Demos, Tutorials, and Panels. Before submission, please check and comply with the Editorial rules: http://www.iaria.org/editorialrules.html AP2PS 2011 Topics (topics and submission details: see CfP on the site) Architectures and protocols Search protocols; Publish and subscribe systems; Overlay based multicast; Multilayer systems; Locality awareness; Gossip-based and epidemic protocols; Integration with network operators and service providers; Autonomic computing and networking; Semantic P2P; Opportunistic networking Applications Content delivery networks; Cloud computing; Public resource computing; Aggregate computing; Web services; Computational, service, and storage Grids; Voice and video streaming and IPTV; Collaborative platforms and social networks ; Network management; Wireless sensor networks; Scientific computing and workflow management systems; Green computing Prototypes and simulations Implementations; Comparative performance analysis; Dependability, resilience and availability; Scalability; Stability; Benchmarking and optimization; Quality of experience Security, trust and reputation Privacy & Anonymity; Trust and reputation management; Free-riding prevention; Authentication and identity management; Fairness and Incentive models; Virtual economies; Digital rights management; Content filtering P2P and wireless convergence P2P in cellular networks; P2P in wireless networks; P2P in ad hoc networks; Integrated approaches; Energy efficiency ---------------------- AP2PS General Chairs Nick Antonopoulos, University of Derby, UK Antonio Liotta, Eindhoven University of Technology, The Netherlands Giuseppe Di Fatta, The University of Reading, UK AP2PS Advisory Chairs Marco Aiello, University of Groningen, The Netherlands Takahiro Hara, University of Osaka, Japan Ouri Wolfson, University of Illinois at Chicago, USA AP2PS 2011 Industry Liaison Chair Christoph Schuba, Oracle Corp., USA Roman Y. Shtykh, Rakuten, Inc., Japan AP2PS 2011 Research Chairs Yasushi Kambayashi, Nippon Institute of Technology, Japan Anders Fongen, Norwegian Defense Research Establishment, Norway Quang Hieu Vu, ETISALAT BT Innovation Center (EBTIC)/ Khalifa University, UAE Committee: http://www.iaria.org/conferences2011/ComAP2PS11.html ==================== From tjc at ecs.soton.ac.uk Fri Jun 24 17:36:55 2011 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Fri, 24 Jun 2011 16:36:55 +0100 Subject: [ipv6-wg] IETF working group on renumbering in IPv6 In-Reply-To: <1308650313.3570.19.camel@shane-desktop> References: <1308650313.3570.19.camel@shane-desktop> <8FDC0030-D1E7-4197-9070-CAB7ABAD145C@ecs.soton.ac.uk> Message-ID: Hi Shane, Many thanks for advertising the new WG to these lists. The charter was refined further since the one below, the final one being listed here: http://datatracker.ietf.org/wg/6renum/charter/ We would welcome any contributions to the renum mail list, see: https://www.ietf.org/mailman/listinfo/renum Currently I am one chair for the WG, another is being sought. I'm very happy to take any comments or inputs directly if people have views but do not wish to join the mail list. There should be a 6renum WG slot in Quebec at IETF81. I hope to attend RIPE63, so perhaps we can also have a slot for this in the IPv6 WG session there. Many thanks, Tim On 21 Jun 2011, at 10:58, Shane Kerr wrote: > All, > > There is some idea to work on the renumbering problem in IPv6. > > This is certainly of interest to IPv6 folks, but I am including the > address policy folks as this may ultimately have impact there. > > Cheers, > > -- > Shane > > From: IESG Secretary > Date: 2 June 2011 18:54:54 GMT+01:00 > To: IETF Announcement list > Cc: renum at ietf.org > Subject: WG Review: IPv6 Site Renumbering (6renum) > Reply-To: iesg at ietf.org > > > A new IETF working group has been proposed in the Operations and > Management Area. The IESG has not made any determination as yet. The > following draft charter was submitted, and is provided for informational > purposes only. Please send your comments to the IESG mailing list > (iesg at ietf.org) by Thursday, June 9, 2011 > > IPv6 Site Renumbering (6renum) > ------------------------------- > Last Modified: 2011-06-02 > > Current Status: Proposed Working Group > > Chairs: TBD > > Area Director: Ron Bonica > > Mailing list > Address: renum at ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/renum > Archive: http://www.ietf.org/mail-archive/web/renum/ > > Description of Working Group > ----------- > > As outlined in RFC 5887, renumbering, especially for medium to large > sites and networks, is currently viewed as an expensive, painful, and > error-prone process, avoided by network managers as much as possible. > > As IPv6 adoption begins to gather momentum, those managers may turn to > PI addressing for IPv6 to attempt to minimise the need for future > renumbering. However, such an approach would create very serious BGP4 > scaling problems if used by millions of end sites; it is thus desirable > to develop tools, techniques and practices that may make renumbering a > simpler process, to reduce demand for IPv6 PI space. In addition, as > RFC 5887 describes, there are other triggers that mean some cases of > renumbering are unavoidable, so it should be considered a given that > a site may need partial or complete renumbering at some stage. > > Strategically it is thus important to implement and deploy techniques > that facilitate simpler IPv6 site renumbering, so that as IPv6 becomes > universally deployed, renumbering can be viewed as a more routine event. > This includes consideration of how the initial assignment and subsequent > management of address information is performed, as this will affect > future renumbering operations. > > For renumbering to become more routine, a systematic address management > approach will be essential. A large site with a short prefix will be > divided into subnets with longer prefixes. In this scenario, renumbering > or partial renumbering can be complicated. Aggregation, synchronisation, > coordination, etc., need to be carefully managed, and the use of > manually inserted address literals minimised. In unmanaged scenarios, > consideration may need to be made for 'flag day' renumbering (in > contrast to the procedure described in RFC4192). > > The task of the 6RENUM working group is to document existing renumbering > practices for managed (enterprise) and unmanaged (SOHO) networks, to > identify specific renumbering problems in the context of site-wide > renumbering, and to then recharter with a view to develop point > solutions and system solutions to address those problems or to stimulate > such development in other working groups if appropriate. The principal > target will be solutions for IPv6. > > RFC 4192, RFC 5887, and draft-jiang-ipv6-site-renum-guideline are > starting points for this work. > > Goals/deliverables > ------------------ > > The goals of the 6RENUM working group are: > > 1. To undertake scenario descriptions, including documentation of > current capability inventories and existing BCPs for managed > (enterprise) and unmanaged (SOHO) networks. These texts should > contribute towards the gap analysis and provide an agreed basis for > subsequent WG rechartering towards development of solutions > (potentially in other WGs) and improved practices. Operator input > will be of particularly high value for this stage. > > 2. To examine fully automatic, self-organising networks (manet/autoconf) > as a possible third scenario. > > 3. To perform a gap analysis for renumbering practices, drawing on RFCs > 4192 and 5887, to identify generic issues for network design, network > management, and renumbering operations. The scenario texts will > contribute to the analysis. > > 4. To document existing IP address management models and practices with > a view to proposing (at a high level) an appropriate model to allow > simplification of any partial or full site renumbering process > (this would likely be applicable to managed rather than unmanaged > scenarios). > > The general methodology for the WG will be to first build managed and > unmanaged baseline scenario descriptions, while in parallel undertaking > an initial gap analysis from existing work in (at least) RFC4192 and > RFC5877. As the scenario texts harden, their contributions will be > incorporated into the gap analysis, which can be published once the > scenarios are completed. > > The following topics are out of scope for the working group: > > 1. Renumbering avoidance; this can perhaps be considered by appropriate > IRTF groups. As documented in RFC5887, renumbering cannot be > completely avoided. The WG is limited to dealing with how to renumber > when it is unavoidable. > > 2. IPv4 renumbering. While many sites are likely to run dual-stack, > IPv6 is the future and, especially given concerns over extensive use > of IPv6 PI, the most appropriate place to focus effort. > > 3. ISP renumbering; this is potentially the most complex renumbering > case. More benefit can be achieved by focusing effort on site > renumbering. The site analysis should include the ISP's role in its > own renumbering event. > > A recharter of the WG will be possible once the gap analysis and > scenario descriptions are completed, and the IP address management > ('numbering tool') review and (high level) proposal have been published. > The rechartering will identify more specific work items within the > 6RENUM WG or appropriate protocol WGs. > > Milestones > ---------- > > Aug 2011 managed (enterprise) scenario draft ready for WG adoption > (partly based on draft-jiang-ipv6-site-renum-guideline) > > Aug 2011 unmanaged (SOHO) scenario draft ready for WG adoption > > Oct 2011 gap analysis document ready for WG adoption (already some > considerations in RFC5887 and > draft-jiang-ipv6-site-renum-guideline) > > Oct 2011 management model draft ready for WG adoption > > Jan 2012 managed (enterprise) scenario draft ready for WGLC > > Jan 2012 unmanaged (SOHO) scenario draft ready for WGLC > > Feb 2012 management model ready for WGLC > > Mar 2012 gap analysis document ready for WGLC > > Apr 2012 recharter WG towards solution space > > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce at ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mir at ripe.net Tue Jun 28 10:49:21 2011 From: mir at ripe.net (Mirjam Kuehne) Date: Tue, 28 Jun 2011 10:49:21 +0200 Subject: [ipv6-wg] New article to RIPE Labs: Measuring World IPv6 Day Message-ID: <4E099591.2050802@ripe.net> [apologies for duplicates] Dear colleagues, Please find a new articles on RIPE Labs: Measuring World IPv6 Day - Some Glitches and Lessons Learned http://labs.ripe.net/Members/emileaben/measuring-world-ipv6-day-glitches-and-lessons-learned Kind Regards, Mirjam Kuehne RIPE NCC