From james at ripe.net Tue Feb 2 15:18:50 2010 From: james at ripe.net (James Aldridge) Date: Tue, 02 Feb 2010 15:18:50 +0100 Subject: [ipv6-wg] IPv6 experiments at future RIPE Meetings Message-ID: <1A6DE1C92A2EE7ABF35B33C0@james-macbook-pro.ripe.net> Reading the minutes of the IPv6 WG at RIPE 59 I read: > David asked the audience if the IPv6 Hour should be rerun at future > meetings.. There is consensus that it should be. Rob Blokzijl has asked that we treat the RIPE Meeting network as a production network. This effectively means that we won't be turning off the dual-stack network for another "IPv6 Hour". What we can do is to build the IPv6 only networks as we did in Berlin and make these available to anyone who wants to use them, but without the complications caused by the IPv6 Hour. One question that remains is whether, with rfc2766 now "historic", providing NAT-PT on the IPv6-only networks is worthwhile for RIPE 60 and future meetings. Would it be enough just to provide the IPv6 networks but without any translation to be able to reach the IPv4 legacy Internet? Any feedback would be appreciated. Regards, James -- James Aldridge, Senior Systems & Network Engineer, RIPE NCC RIPE Meeting technical team From jan at go6.si Tue Feb 2 15:28:19 2010 From: jan at go6.si (Jan Zorz @ go6.si) Date: Tue, 02 Feb 2010 15:28:19 +0100 Subject: [ipv6-wg] IPv6 experiments at future RIPE Meetings In-Reply-To: <1A6DE1C92A2EE7ABF35B33C0@james-macbook-pro.ripe.net> References: <1A6DE1C92A2EE7ABF35B33C0@james-macbook-pro.ripe.net> Message-ID: <4B683683.20402@go6.si> James Aldridge wrote: > One question that remains is whether, with rfc2766 now "historic", > providing NAT-PT on the IPv6-only networks is worthwhile for RIPE 60 and > future meetings. Would it be enough just to provide the IPv6 networks > but without any translation to be able to reach the IPv4 legacy Internet? Is there any NAT64/DNS64 mechanism out there in running-code yet? I hear Cisco will deploy this in some experimental IOS later this year. I suspect this also to be crap like NAT-PT, but we never know... /jan From andy at nosignal.org Tue Feb 2 15:31:57 2010 From: andy at nosignal.org (Andy Davidson) Date: Tue, 02 Feb 2010 14:31:57 +0000 Subject: [ipv6-wg] IPv6 experiments at future RIPE Meetings In-Reply-To: <1A6DE1C92A2EE7ABF35B33C0@james-macbook-pro.ripe.net> References: <1A6DE1C92A2EE7ABF35B33C0@james-macbook-pro.ripe.net> Message-ID: <4B68375D.2020403@nosignal.org> On 02/02/2010 14:18, James Aldridge wrote: > Reading the minutes of the IPv6 WG at RIPE 59 I read: >> David asked the audience if the IPv6 Hour should be rerun at future >> meetings.. There is consensus that it should be. > Rob Blokzijl has asked that we treat the RIPE Meeting network as a > production network. This effectively means that we won't be turning off > the dual-stack network for another "IPv6 Hour". [...] > Any feedback would be appreciated. Thank you. A good position, James. There is a difference between advocacy and forcing v6 down peoples' throats. Proving the dual-stack model works is important enough. Maybe we can force dual stack down people's throats by forcing a registration portal that was only available via v6, once complete you had access to the production dual stack network ? ;-) Andy From marc.blanchet at viagenie.ca Tue Feb 2 15:31:58 2010 From: marc.blanchet at viagenie.ca (Marc Blanchet) Date: Tue, 02 Feb 2010 09:31:58 -0500 Subject: [ipv6-wg] IPv6 experiments at future RIPE Meetings In-Reply-To: <1A6DE1C92A2EE7ABF35B33C0@james-macbook-pro.ripe.net> References: <1A6DE1C92A2EE7ABF35B33C0@james-macbook-pro.ripe.net> Message-ID: <4B68375E.90201@viagenie.ca> James Aldridge a ?crit : > Reading the minutes of the IPv6 WG at RIPE 59 I read: >> David asked the audience if the IPv6 Hour should be rerun at future >> meetings.. There is consensus that it should be. > > Rob Blokzijl has asked that we treat the RIPE Meeting network as a > production network. This effectively means that we won't be turning off > the dual-stack network for another "IPv6 Hour". > > What we can do is to build the IPv6 only networks as we did in Berlin > and make these available to anyone who wants to use them, but without > the complications caused by the IPv6 Hour. > > One question that remains is whether, with rfc2766 now "historic", > providing NAT-PT on the IPv6-only networks is worthwhile for RIPE 60 and > future meetings. Would it be enough just to provide the IPv6 networks > but without any translation to be able to reach the IPv4 legacy Internet? we have an implementation of nat64 that we will be running in a well-known internet engineering conference in the next weeks for that reason. We could bring it to RIPE if you like. Marc. > > Any feedback would be appreciated. > > Regards, > James > From shane at time-travellers.org Tue Feb 2 15:53:11 2010 From: shane at time-travellers.org (Shane Kerr) Date: Tue, 02 Feb 2010 15:53:11 +0100 Subject: [ipv6-wg] IPv6 experiments at future RIPE Meetings In-Reply-To: <1A6DE1C92A2EE7ABF35B33C0@james-macbook-pro.ripe.net> References: <1A6DE1C92A2EE7ABF35B33C0@james-macbook-pro.ripe.net> Message-ID: <4B683C57.2000109@time-travellers.org> James, On 2010-02-02 15:18, James Aldridge wrote: > Reading the minutes of the IPv6 WG at RIPE 59 I read: >> David asked the audience if the IPv6 Hour should be rerun at future >> meetings.. There is consensus that it should be. > > Rob Blokzijl has asked that we treat the RIPE Meeting network as a > production network. This effectively means that we won't be turning off > the dual-stack network for another "IPv6 Hour". Sure, makes sense. > What we can do is to build the IPv6 only networks as we did in Berlin > and make these available to anyone who wants to use them, but without > the complications caused by the IPv6 Hour. > > One question that remains is whether, with rfc2766 now "historic", > providing NAT-PT on the IPv6-only networks is worthwhile for RIPE 60 and > future meetings. Would it be enough just to provide the IPv6 networks > but without any translation to be able to reach the IPv4 legacy Internet? > > Any feedback would be appreciated. For the IPV6-only with translation, we should consider one of the transition tools now available. ISC (my company, although I have had no involvement with this software) just released AFTR: https://www.isc.org/software/aftr It's open source, gratis, libre, and so on. I do think RIPE meetings should switch to RFC 1918 addresses for both IPv4/IPv6 and IPv4-only networks ASAP. These are heavily used, even in production networks. Probably too late for the next RIPE meeting, but shouldn't be a problem for subsequent ones. -- Shane From cfriacas at fccn.pt Tue Feb 2 15:56:13 2010 From: cfriacas at fccn.pt (Carlos Friacas) Date: Tue, 2 Feb 2010 14:56:13 +0000 (WET) Subject: [ipv6-wg] IPv6 experiments at future RIPE Meetings In-Reply-To: <1A6DE1C92A2EE7ABF35B33C0@james-macbook-pro.ripe.net> References: <1A6DE1C92A2EE7ABF35B33C0@james-macbook-pro.ripe.net> Message-ID: Hi James & all, I missed the "Berlin experiment" and i honestly feel those experiments are only useful to allow "IPv6 advocates" to check if they can really live/function without the "safety net" that IPv4 really is. :-) I already know i can have 100% functionality with IPv6-only, because there is some stuff on my domain that i have absolutely no control. IMHO, for the meeting "neutral attendee" this kind of experiment may become a pain, and it may, to some extent, create/increase resistance to IPv6 usage/deployment. So, if the NCC is interested in allowing people to test how ready they really are to survive without IPv4 i would advice on installing one wifi access point a bit away from where most people concentrate, and clearly tag that area as "No IPv4 available here". You might even want to "stamp" the floor with colorful arrows driving people for the edge "Test-how-will-you-survive-without-v4" zone. :-)) Best Regards, Carlos On Tue, 2 Feb 2010, James Aldridge wrote: > Reading the minutes of the IPv6 WG at RIPE 59 I read: >> David asked the audience if the IPv6 Hour should be rerun at future >> meetings.. There is consensus that it should be. > > Rob Blokzijl has asked that we treat the RIPE Meeting network as a production > network. This effectively means that we won't be turning off the dual-stack > network for another "IPv6 Hour". > > What we can do is to build the IPv6 only networks as we did in Berlin and > make these available to anyone who wants to use them, but without the > complications caused by the IPv6 Hour. > > One question that remains is whether, with rfc2766 now "historic", providing > NAT-PT on the IPv6-only networks is worthwhile for RIPE 60 and future > meetings. Would it be enough just to provide the IPv6 networks but without > any translation to be able to reach the IPv4 legacy Internet? > > Any feedback would be appreciated. > > Regards, > James > > -- > James Aldridge, Senior Systems & Network Engineer, RIPE NCC > RIPE Meeting technical team > > From gert at space.net Tue Feb 2 16:21:48 2010 From: gert at space.net (Gert Doering) Date: Tue, 2 Feb 2010 16:21:48 +0100 Subject: [ipv6-wg] IPv6 experiments at future RIPE Meetings In-Reply-To: <4B683C57.2000109@time-travellers.org> References: <1A6DE1C92A2EE7ABF35B33C0@james-macbook-pro.ripe.net> <4B683C57.2000109@time-travellers.org> Message-ID: <20100202152148.GI3692@Space.Net> Hi, On Tue, Feb 02, 2010 at 03:53:11PM +0100, Shane Kerr wrote: > On 2010-02-02 15:18, James Aldridge wrote: > > Rob Blokzijl has asked that we treat the RIPE Meeting network as a > > production network. [..] > > I do think RIPE meetings should switch to RFC 1918 addresses for both > IPv4/IPv6 and IPv4-only networks ASAP. "Production network" is not compatible with "RFC 1918" addresses. There is no need to make IPv4 available-but-less-useful - if we don't want IPv4, let's turn it off, but don't pretend. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 144438 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From shane at time-travellers.org Tue Feb 2 16:58:36 2010 From: shane at time-travellers.org (Shane Kerr) Date: Tue, 02 Feb 2010 16:58:36 +0100 Subject: [ipv6-wg] RFC 1918 in "production networks" (was IPv6 experiments at future RIPE Meetings) In-Reply-To: <20100202152148.GI3692@Space.Net> References: <1A6DE1C92A2EE7ABF35B33C0@james-macbook-pro.ripe.net> <4B683C57.2000109@time-travellers.org> <20100202152148.GI3692@Space.Net> Message-ID: <4B684BAC.7010109@time-travellers.org> Gert, On 2010-02-02 16:21, Gert Doering wrote: > Hi, > > On Tue, Feb 02, 2010 at 03:53:11PM +0100, Shane Kerr wrote: >> On 2010-02-02 15:18, James Aldridge wrote: >>> Rob Blokzijl has asked that we treat the RIPE Meeting network as a >>> production network. [..] >> >> I do think RIPE meetings should switch to RFC 1918 addresses for both >> IPv4/IPv6 and IPv4-only networks ASAP. > > "Production network" is not compatible with "RFC 1918" addresses. > > There is no need to make IPv4 available-but-less-useful - if we don't > want IPv4, let's turn it off, but don't pretend. I kind of understand where you're coming from. You hate NAT. It is a common position of anyone who has had to work with it. :) But the idea that no production networks can use RFC 1918 is a bit disturbing, because in 2 years or so there won't be any IPv4 addresses left, and people will be forced to use RFC 1918 addresses. Does that mean there won't be any IPv4 production networks in 2013? My intention is not to make IPv4 available-but-less-useful, but rather to begin using the same setup that all event organizers will have to use in the future. It's not that bad, really - I use RFC 1918 networks all the time. I'm using one now (well, except for the 0.01% of the Internet with working IPv6). The Internet seems to work pretty good with RFC 1918 + IPv6. -- Shane From gert at space.net Tue Feb 2 17:07:48 2010 From: gert at space.net (Gert Doering) Date: Tue, 2 Feb 2010 17:07:48 +0100 Subject: [ipv6-wg] RFC 1918 in "production networks" (was IPv6 experiments at future RIPE Meetings) In-Reply-To: <4B684BAC.7010109@time-travellers.org> References: <1A6DE1C92A2EE7ABF35B33C0@james-macbook-pro.ripe.net> <4B683C57.2000109@time-travellers.org> <20100202152148.GI3692@Space.Net> <4B684BAC.7010109@time-travellers.org> Message-ID: <20100202160748.GJ3692@Space.Net> Hi, On Tue, Feb 02, 2010 at 04:58:36PM +0100, Shane Kerr wrote: > But the idea that no production networks can use RFC 1918 is a bit > disturbing, because in 2 years or so there won't be any IPv4 addresses > left, and people will be forced to use RFC 1918 addresses. Does that > mean there won't be any IPv4 production networks in 2013? IPv4 is clearly last century's IP protocol... you know that. In 2013, existing IPv4 production networks will continue to work, of course - and new IPv4 deployments will feel massive amounts of pains. And no, I don't consider "new IPv4 networks without available address space" to be "production networks". > My intention is not to make IPv4 available-but-less-useful, but rather > to begin using the same setup that all event organizers will have to use > in the future. Why should we run with the masses? What will be next, "turn off IPv6 because all the other event organizers don't have v6 either"? *shake head* > It's not that bad, really - I use RFC 1918 networks all > the time. I'm using one now (well, except for the 0.01% of the Internet > with working IPv6). The Internet seems to work pretty good with RFC 1918 > + IPv6. This is not "Internet". This is "I go out and pull stuff from servers that are run in real IP Space". Internet means "having machines that are reachable without major contortions on the devices in between" (= NAT forwardings). (despite the religious aspects, there's a purely practical aspect - if you force RIPE attendees into RFC1918 space, you're going to kill VPN connects for those poor souls that have a home network in the *same* RFC1918 address range. Which will break almost all VPN clients out there.) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 144438 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From zbynek at dialtelecom.cz Tue Feb 2 16:42:31 2010 From: zbynek at dialtelecom.cz (Zbynek Pospichal) Date: Tue, 02 Feb 2010 16:42:31 +0100 Subject: [ipv6-wg] IPv6 experiments at future RIPE Meetings In-Reply-To: References: <1A6DE1C92A2EE7ABF35B33C0@james-macbook-pro.ripe.net> Message-ID: <4B6847E7.2000403@dialtelecom.cz> Hi, I see plain IPv6 without any kind of IPv4 support including protocol translation as very nice idea there. People could see how much (or how few if I would like to be accurate and/or sarcastic) of public and their own private services like their SSH, POP3, SMTP or IM accounts could be reached by IPv6. It could be also a motivation for a lot of people to make more services v6 available *before* the meeting. I see a lot of v6 enabled networks but only a small amount of v6 enabled services. BR, Zbynek Dne 2.2.10 15:56, Carlos Friacas napsal(a): > > Hi James & all, > > I missed the "Berlin experiment" and i honestly feel those experiments > are only useful to allow "IPv6 advocates" to check if they can really > live/function without the "safety net" that IPv4 really is. :-) > > I already know i can have 100% functionality with IPv6-only, because > there is some stuff on my domain that i have absolutely no control. > > IMHO, for the meeting "neutral attendee" this kind of experiment may > become a pain, and it may, to some extent, create/increase resistance to > IPv6 usage/deployment. > > So, if the NCC is interested in allowing people to test how ready they > really are to survive without IPv4 i would advice on installing one wifi > access point a bit away from where most people concentrate, and clearly > tag that area as "No IPv4 available here". > You might even want to "stamp" the floor with colorful arrows driving > people for the edge "Test-how-will-you-survive-without-v4" zone. :-)) > > > Best Regards, > Carlos From jan at go6.si Tue Feb 2 17:39:53 2010 From: jan at go6.si (Jan Zorz @ go6.si) Date: Tue, 02 Feb 2010 17:39:53 +0100 Subject: [ipv6-wg] RFC 1918 in "production networks" (was IPv6 experiments at future RIPE Meetings) In-Reply-To: <4B684BAC.7010109@time-travellers.org> References: <1A6DE1C92A2EE7ABF35B33C0@james-macbook-pro.ripe.net> <4B683C57.2000109@time-travellers.org> <20100202152148.GI3692@Space.Net> <4B684BAC.7010109@time-travellers.org> Message-ID: <4B685559.9030803@go6.si> Shane Kerr wrote: > But the idea that no production networks can use RFC 1918 is a bit > disturbing, because in 2 years or so there won't be any IPv4 addresses > left, and people will be forced to use RFC 1918 addresses. Does that > mean there won't be any IPv4 production networks in 2013? Shane, Please, don't push the CGN(or LSN) idea any further. NAT-ing the whole ISP networks would permanently kill end2end paradigm. I don't want to see my whole city or even country to operate in RFC1918 address space behind one big NAT in near future. Sorry, I agree with Gert. :) /jan From riccardo at e4a.it Tue Feb 2 18:34:28 2010 From: riccardo at e4a.it (Riccardo Losselli) Date: Tue, 02 Feb 2010 18:34:28 +0100 Subject: [ipv6-wg] RFC 1918 in "production networks" (was IPv6 experiments at future RIPE Meetings) In-Reply-To: <20100202160748.GJ3692@Space.Net> References: <1A6DE1C92A2EE7ABF35B33C0@james-macbook-pro.ripe.net> <4B683C57.2000109@time-travellers.org> <20100202152148.GI3692@Space.Net> <4B684BAC.7010109@time-travellers.org> <20100202160748.GJ3692@Space.Net> Message-ID: <4B686224.8050206@e4a.it> Hi, i must say i second Gert and Jan their position against the use of NAT, for pretty much the same stated reasons. Apart from all the tecnical details of what will work/not work/possible not work, and any personal position about the good and the bad of NATting, please note that enabling NAT on the meeting network would be against the currently running laws of at least one of the country hosting one of the next RIPE meetings: Italy (for any of you interested on it it's art. 6, comma 5, d.lgs 109/2008) Which, roughly translated, states that starting from march 21 2009 "any access provider, providing public connectivity (which means connecting people to the Internet), must ensure effective avalability and unicity of ip addresses assigned to the end user. Which means that if you want to comply to the law you MUST assign a public ip address to any user you connect (and by the way if you give internet access on public locations you should also be able to track down the identity of each single user that has connected, including a copy of an ID document or some other allowed certain identification methods). No need to comment on that law, no one here in Italy really likes it at all, but that's it, up to now, and at least until next december 31st we do have to live with it. I think the chances of network abuses during a RIPE meeting are quite low, but i really would avoid seeing a RIPE meeting pushing, even if indirectly and unwanted, some unlawful behaviour. Thanks, Ricky From dburk at burkov.aha.ru Tue Feb 2 19:43:48 2010 From: dburk at burkov.aha.ru (Dmitry Burkov) Date: Tue, 02 Feb 2010 21:43:48 +0300 Subject: [ipv6-wg] RFC 1918 in "production networks" (was IPv6 experiments at future RIPE Meetings) In-Reply-To: <20100202160748.GJ3692@Space.Net> References: <1A6DE1C92A2EE7ABF35B33C0@james-macbook-pro.ripe.net> <4B683C57.2000109@time-travellers.org> <20100202152148.GI3692@Space.Net> <4B684BAC.7010109@time-travellers.org> <20100202160748.GJ3692@Space.Net> Message-ID: <4B687264.3080909@burkov.aha.ru> On 02.02.10 19:07, Gert Doering wrote: > > (despite the religious aspects, there's a purely practical aspect - if > you force RIPE attendees into RFC1918 space, you're going to kill VPN > connects for those poor souls that have a home network in the *same* > RFC1918 address range. Which will break almost all VPN clients out there.) > Gert, seems you dramatize the situation - there are more issues - to be honest. The situations can be more complex. But I don't see any specific differences with access to corporate intranets and still had no problem in such mixed enviroments using appropriative tools for years. Dima > Gert Doering > -- NetMaster > From gert at space.net Tue Feb 2 21:36:10 2010 From: gert at space.net (Gert Doering) Date: Tue, 2 Feb 2010 21:36:10 +0100 Subject: [ipv6-wg] RFC 1918 in "production networks" (was IPv6 experiments at future RIPE Meetings) In-Reply-To: <4B687264.3080909@burkov.aha.ru> References: <1A6DE1C92A2EE7ABF35B33C0@james-macbook-pro.ripe.net> <4B683C57.2000109@time-travellers.org> <20100202152148.GI3692@Space.Net> <4B684BAC.7010109@time-travellers.org> <20100202160748.GJ3692@Space.Net> <4B687264.3080909@burkov.aha.ru> Message-ID: <20100202203610.GK3692@Space.Net> Hi, On Tue, Feb 02, 2010 at 09:43:48PM +0300, Dmitry Burkov wrote: > On 02.02.10 19:07, Gert Doering wrote: > > > > (despite the religious aspects, there's a purely practical aspect - if > > you force RIPE attendees into RFC1918 space, you're going to kill VPN > > connects for those poor souls that have a home network in the *same* > > RFC1918 address range. Which will break almost all VPN clients out there.) > > > Gert, > seems you dramatize the situation > - there are more issues - to be honest. > The situations can be more complex. > But I don't see any specific differences with access to corporate > intranets and If we use 192.168.1.0/24 for the RIPE meeting, and your corporate network at home uses 192.168.1.0/24 as well, most VPN clients will NOT be able to build a working connection. Try it. Given the number of attendees, the chances for address collisions with at least one participant's home network can be assumed to be near 100%. We've been fighting with this issue for years now - people stay at hotels and want to connect to their home network, and that network happens to use the same RFC 1918 address block as the hotel. (Add to that the problems many N:1 NAT/PAT implementations have with multiple parallel IPSEC sessions). NAT and RFC1918 are fine tools for corporate environments that don't *want* any communication besides clearly defined exceptions. But that's not "useful Internet". Don't go there, just "because everbody else does". (*Especially* not for that stupid reason. We're not sheep.) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 144438 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From david.kessens at nsn.com Wed Feb 3 00:43:48 2010 From: david.kessens at nsn.com (David Kessens) Date: Tue, 2 Feb 2010 15:43:48 -0800 Subject: [ipv6-wg] RFC 1918 in "production networks" (was IPv6 experiments at future RIPE Meetings) In-Reply-To: <20100202203610.GK3692@Space.Net> References: <1A6DE1C92A2EE7ABF35B33C0@james-macbook-pro.ripe.net> <4B683C57.2000109@time-travellers.org> <20100202152148.GI3692@Space.Net> <4B684BAC.7010109@time-travellers.org> <20100202160748.GJ3692@Space.Net> <4B687264.3080909@burkov.aha.ru> <20100202203610.GK3692@Space.Net> Message-ID: <20100202234347.GF4736@nsn.com> Gert, On Tue, Feb 02, 2010 at 09:36:10PM +0100, Gert Doering wrote: > > Given the number of attendees, the chances for address collisions with > at least one participant's home network can be assumed to be near 100%. So use NAT'ed public IPv4 addresses ? (yuk!) But seriously, we will be living in this ugly world not long from now, whether we like it or not. Why not try it out before it will be forced on us? At least this time you can relatively easy bypass the NAT by using IPv6 and there is still time to find out about the worst problems like you mention above and make it work. David Kessens --- From david.kessens at nsn.com Wed Feb 3 00:51:47 2010 From: david.kessens at nsn.com (David Kessens) Date: Tue, 2 Feb 2010 15:51:47 -0800 Subject: [ipv6-wg] Request for approval of the minutes for wg session RIPE 59 (20100207) In-Reply-To: References: <20100129063800.GB2654@nsn.com> Message-ID: <20100202235146.GH4736@nsn.com> Sander, On Sat, Jan 30, 2010 at 10:15:32PM +0100, Sander Steffann wrote: > > I remember the following part differently: > > > Rob said that the WG should take things slowly, and propose a new > > charter at the next RIPE Meeting and that further discussions should > > continue on the mailing list. > > I think Rob said that the new charter should be in place at the next > RIPE meeting, and that the next session of the IPv6 working group > should be organized using the new charter. I will go after this and see if we can find out what really was said. In any case, it isn't that important anymore as we already have a new charter in place. David Kessens --- From leo.vegoda at icann.org Wed Feb 3 01:20:55 2010 From: leo.vegoda at icann.org (Leo Vegoda) Date: Tue, 2 Feb 2010 16:20:55 -0800 Subject: [ipv6-wg] RFC 1918 in "production networks" (was IPv6 experiments at future RIPE Meetings) In-Reply-To: <20100202234347.GF4736@nsn.com> References: <1A6DE1C92A2EE7ABF35B33C0@james-macbook-pro.ripe.net> <4B683C57.2000109@time-travellers.org> <20100202152148.GI3692@Space.Net> <4B684BAC.7010109@time-travellers.org> <20100202160748.GJ3692@Space.Net> <4B687264.3080909@burkov.aha.ru> <20100202203610.GK3692@Space.Net> <20100202234347.GF4736@nsn.com> Message-ID: On Feb 2, 2010, at 3:43 PM, David Kessens wrote: [?] > But seriously, we will be living in this ugly world not long from now, > whether we like it or not. Why not try it out before it will be forced > on us? I agree with this statement. I think there is real value in experiencing the kinds of problems we are likely to see when the IPv4 address space has been fully allocated and further network growth cannot use unique IPv4 addresses. Having an optional CGN-style network to see what works and what needs to be improved would be genuinely useful. Regards, Leo Vegoda From sander at steffann.nl Wed Feb 3 08:31:29 2010 From: sander at steffann.nl (Sander Steffann) Date: Wed, 3 Feb 2010 08:31:29 +0100 Subject: [ipv6-wg] Request for approval of the minutes for wg session RIPE 59 (20100207) In-Reply-To: <20100202235146.GH4736@nsn.com> References: <20100129063800.GB2654@nsn.com> <20100202235146.GH4736@nsn.com> Message-ID: <4DC750CE-2018-4F8E-A129-F796A1F5C3FB@steffann.nl> Hi David, > On Sat, Jan 30, 2010 at 10:15:32PM +0100, Sander Steffann wrote: >> >> I remember the following part differently: >> >>> Rob said that the WG should take things slowly, and propose a new >>> charter at the next RIPE Meeting and that further discussions should >>> continue on the mailing list. >> >> I think Rob said that the new charter should be in place at the next >> RIPE meeting, and that the next session of the IPv6 working group >> should be organized using the new charter. > > I will go after this and see if we can find out what really was said. I believe it's around minute 52 of the webcast. Sander From millnert at csbnet.se Wed Feb 3 09:59:31 2010 From: millnert at csbnet.se (Martin Millnert) Date: Wed, 03 Feb 2010 09:59:31 +0100 Subject: [ipv6-wg] Youtube over IPv6! In-Reply-To: <1264793600.1613.144.camel@hsa.vpn.anti> References: <1264793600.1613.144.camel@hsa.vpn.anti> Message-ID: <1265187571.28198.32.camel@hsa.vpn.anti> Hi again list, just a quick update for the jedi archives: On Fri, 2010-01-29 at 20:33 +0100, Martin Millnert wrote: > The www.youtube.com user interface so far does *not* have any AAAA > published, but the *much* more important (traffic wise) image and video > servers do. Use tcpdump to verify. anticimex at hsa:~$ host www.youtube.com www.youtube.com is an alias for youtube-ui.l.google.com. youtube-ui.l.google.com has address 74.125.39.102 youtube-ui.l.google.com has address 74.125.39.113 youtube-ui.l.google.com has address 74.125.39.138 youtube-ui.l.google.com has address 74.125.39.139 youtube-ui.l.google.com has address 74.125.39.100 youtube-ui.l.google.com has address 74.125.39.101 youtube-ui.l.google.com has IPv6 address 2a00:1450:8007::66 youtube-ui.l.google.com has IPv6 address 2a00:1450:8007::71 youtube-ui.l.google.com has IPv6 address 2a00:1450:8007::8a youtube-ui.l.google.com has IPv6 address 2a00:1450:8007::8b youtube-ui.l.google.com has IPv6 address 2a00:1450:8007::64 youtube-ui.l.google.com has IPv6 address 2a00:1450:8007::65 Great work guys! If now only Googles DNS infrastructure was dual-stacked... ;-) Regards, -- Martin Millnert -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From gert at space.net Wed Feb 3 09:59:59 2010 From: gert at space.net (Gert Doering) Date: Wed, 3 Feb 2010 09:59:59 +0100 Subject: [ipv6-wg] RFC 1918 in "production networks" (was IPv6 experiments at future RIPE Meetings) In-Reply-To: <20100202234347.GF4736@nsn.com> References: <1A6DE1C92A2EE7ABF35B33C0@james-macbook-pro.ripe.net> <4B683C57.2000109@time-travellers.org> <20100202152148.GI3692@Space.Net> <4B684BAC.7010109@time-travellers.org> <20100202160748.GJ3692@Space.Net> <4B687264.3080909@burkov.aha.ru> <20100202203610.GK3692@Space.Net> <20100202234347.GF4736@nsn.com> Message-ID: <20100203085959.GO3692@Space.Net> Hi, On Tue, Feb 02, 2010 at 03:43:48PM -0800, David Kessens wrote: > On Tue, Feb 02, 2010 at 09:36:10PM +0100, Gert Doering wrote: > > > > Given the number of attendees, the chances for address collisions with > > at least one participant's home network can be assumed to be near 100%. > > So use NAT'ed public IPv4 addresses ? (yuk!) > > But seriously, we will be living in this ugly world not long from now, > whether we like it or not. Why not try it out before it will be forced > on us? I'm sure that whoever wants to break their IPv4 connectivity can nicely do so at home. "Just because IPv4 is broken for people" is no compelling argument to reduce the usefulness of the meeting network for those that have no IPv6 yet. > At least this time you can relatively easy bypass the NAT by using IPv6 > and there is still time to find out about the worst problems like you > mention above and make it work. *I* could live quite well with an IPv6-only network. But that's not the point. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 144438 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From gert at space.net Wed Feb 3 10:01:38 2010 From: gert at space.net (Gert Doering) Date: Wed, 3 Feb 2010 10:01:38 +0100 Subject: [ipv6-wg] RFC 1918 in "production networks" (was IPv6 experiments at future RIPE Meetings) In-Reply-To: References: <1A6DE1C92A2EE7ABF35B33C0@james-macbook-pro.ripe.net> <4B683C57.2000109@time-travellers.org> <20100202152148.GI3692@Space.Net> <4B684BAC.7010109@time-travellers.org> <20100202160748.GJ3692@Space.Net> <4B687264.3080909@burkov.aha.ru> <20100202203610.GK3692@Space.Net> <20100202234347.GF4736@nsn.com> Message-ID: <20100203090138.GP3692@Space.Net> Hi, On Tue, Feb 02, 2010 at 04:20:55PM -0800, Leo Vegoda wrote: > > But seriously, we will be living in this ugly world not long from now, > > whether we like it or not. Why not try it out before it will be forced > > on us? > > I agree with this statement. I think there is real value in > experiencing the kinds of problems we are likely to see when the > IPv4 address space has been fully allocated and further network > growth cannot use unique IPv4 addresses. Having an optional CGN-style > network to see what works and what needs to be improved would be > genuinely useful. At the beginning of this thread, it was stated that the RIPE meeting network is not to be treated as an experiment or testbed. If people think there is an interest in having a NAT-broken network around, then please make it available on a dedicated SSID, but don't experiment with the meeting network. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 144438 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From millnert at csbnet.se Wed Feb 3 10:58:01 2010 From: millnert at csbnet.se (Martin Millnert) Date: Wed, 03 Feb 2010 10:58:01 +0100 Subject: [ipv6-wg] RFC 1918 in "production networks" (was IPv6 experiments at future RIPE Meetings) In-Reply-To: <20100203090138.GP3692@Space.Net> References: <1A6DE1C92A2EE7ABF35B33C0@james-macbook-pro.ripe.net> <4B683C57.2000109@time-travellers.org> <20100202152148.GI3692@Space.Net> <4B684BAC.7010109@time-travellers.org> <20100202160748.GJ3692@Space.Net> <4B687264.3080909@burkov.aha.ru> <20100202203610.GK3692@Space.Net> <20100202234347.GF4736@nsn.com> <20100203090138.GP3692@Space.Net> Message-ID: <1265191081.28198.87.camel@hsa.vpn.anti> On Wed, 2010-02-03 at 10:01 +0100, Gert Doering wrote: > If people think there is an interest in having a NAT-broken network > around, then please make it available on a dedicated SSID, but don't > experiment with the meeting network. Long version: After having read this thread, this one paragraph by Geert makes a lot of sense. Points made in this thread were, in the order my client presented them to me: 1) Do not experiment with the RIPE meeting network 2) Do not push single-stack IPv6 down people's throat 3) Do push bleeding IPv4 down people's throat 4) Testing out what the rest of the world shortly will experience is useful Given 1), it makes a lot of sense to put 2) + 3) on a separate SSID. Give it a well-descriptive name and that's it... Problem solved! Attendees can do testing on their *own* terms, which is bound to make them happier. Short version: I second this statement. :) Regards, -- Martin Millnert -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From mtinka at globaltransit.net Wed Feb 3 11:13:40 2010 From: mtinka at globaltransit.net (Mark Tinka) Date: Wed, 3 Feb 2010 18:13:40 +0800 Subject: [ipv6-wg] RFC 1918 in "production networks" (was IPv6 experiments at future RIPE Meetings) In-Reply-To: <1265191081.28198.87.camel@hsa.vpn.anti> References: <1A6DE1C92A2EE7ABF35B33C0@james-macbook-pro.ripe.net> <20100203090138.GP3692@Space.Net> <1265191081.28198.87.camel@hsa.vpn.anti> Message-ID: <201002031813.44454.mtinka@globaltransit.net> On Wednesday 03 February 2010 05:58:01 pm Martin Millnert wrote: > Given 1), it makes a lot of sense to put 2) + 3) on a > separate SSID. Give it a well-descriptive name and > that's it... Problem solved! Attendees can do testing on > their *own* terms, which is bound to make them happier. This is what we do, shall be doing and have done at a regional meeting in Asia-Pac. Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From shane at time-travellers.org Wed Feb 3 12:07:22 2010 From: shane at time-travellers.org (Shane Kerr) Date: Wed, 03 Feb 2010 12:07:22 +0100 Subject: [ipv6-wg] RFC 1918 in "production networks" (was IPv6 experiments at future RIPE Meetings) In-Reply-To: <1265191081.28198.87.camel@hsa.vpn.anti> References: <1A6DE1C92A2EE7ABF35B33C0@james-macbook-pro.ripe.net> <4B683C57.2000109@time-travellers.org> <20100202152148.GI3692@Space.Net> <4B684BAC.7010109@time-travellers.org> <20100202160748.GJ3692@Space.Net> <4B687264.3080909@burkov.aha.ru> <20100202203610.GK3692@Space.Net> <20100202234347.GF4736@nsn.com> <20100203090138.GP3692@Space.Net> <1265191081.28198.87.camel@hsa.vpn.anti> Message-ID: <4B6958EA.7090402@time-travellers.org> Martin, On 2010-02-03 10:58, Martin Millnert wrote: > On Wed, 2010-02-03 at 10:01 +0100, Gert Doering wrote: >> If people think there is an interest in having a NAT-broken network >> around, then please make it available on a dedicated SSID, but don't >> experiment with the meeting network. > Short version: > > I second this statement. This makes sense. Although of course I would like this to be something like: RIPE 61: ESSID RIPE is globally-unique IPv4+IPv6, ESSID RIPE-NAT is NAT IPv4 plus globally-unique IPv6 RIPE 63: ESSID RIPE is NAT IPv4 plus globally-unique IPv6 ESSID RIPE-NO-NAT is globally unique IPv4+IPv6 In the future we could further mimic the "real world" by charging money for the use of the RIPE-NO-NAT network. For a sufficently massive fee we could probably even keep addresses persistent between meetings. ;) -- Shane From joao at bondis.org Wed Feb 3 12:24:52 2010 From: joao at bondis.org (=?iso-8859-1?Q?Jo=E3o_Damas?=) Date: Wed, 3 Feb 2010 12:24:52 +0100 Subject: [ipv6-wg] RFC 1918 in "production networks" (was IPv6 experiments at future RIPE Meetings) In-Reply-To: <20100203090138.GP3692@Space.Net> References: <1A6DE1C92A2EE7ABF35B33C0@james-macbook-pro.ripe.net> <4B683C57.2000109@time-travellers.org> <20100202152148.GI3692@Space.Net> <4B684BAC.7010109@time-travellers.org> <20100202160748.GJ3692@Space.Net> <4B687264.3080909@burkov.aha.ru> <20100202203610.GK3692@Space.Net> <20100202234347.GF4736@nsn.com> <20100203090138.GP3692@Space.Net> Message-ID: <64017C1E-3764-4EF7-A494-775A173F508D@bondis.org> On 3 Feb 2010, at 10:01, Gert Doering wrote: > > At the beginning of this thread, it was stated that the RIPE meeting > network is not to be treated as an experiment or testbed. > > If people think there is an interest in having a NAT-broken network > around, then please make it available on a dedicated SSID, but don't > experiment with the meeting network. yep, I agree. The last thing I need at a RIPE meeting is to have to spend additional time figuring out how the to get the net working. When attending a RIPE meeting I still need to carry on with normal work, it is not a vacation. Additionally, experiments are better done in controlled situations where one actually has the means to address the findings. BTW, IPv6 ought to continue to be considered as a production service on the RIPE network, just in case. Joao From GeertJan.deGroot at xs4all.nl Wed Feb 3 12:53:43 2010 From: GeertJan.deGroot at xs4all.nl (Geert Jan de Groot) Date: Wed, 03 Feb 2010 12:53:43 +0100 Subject: [ipv6-wg] Re: RFC 1918 in "production networks" In-Reply-To: Your message of "Wed, 03 Feb 2010 12:00:01 +0100." <20100203110001.3607.30612.Mailman@postboy.ripe.net> Message-ID: <20100203115343.A846B5459@berserkly.xs4all.nl> > If we use 192.168.1.0/24 for the RIPE meeting, and your corporate network > at home uses 192.168.1.0/24 as well, most VPN clients will NOT be able > to build a working connection. Try it. > Given the number of attendees, the chances for address collisions with > at least one participant's home network can be assumed to be near 100%. One workaround would be to have two (vastly different) 1918 prefixes and giving people the possibility to switch (so, 2 SSID's, 2 prefixes, say 192.168.224.0/20 and 10.210.32.0/20). Chances that someone will conflict with both, are small. For better or worse, we will need to learn how to deal with this - denying these issues doesn't fix the fact that these situations will happen, without the escape of availability of public IPv4 addresses, in the near future. And, of course, if nobody puts pressure on the VPN-sellers, these issues will stick around for *years*. Geert Jan From gert at space.net Wed Feb 3 13:20:32 2010 From: gert at space.net (Gert Doering) Date: Wed, 3 Feb 2010 13:20:32 +0100 Subject: [ipv6-wg] Re: RFC 1918 in "production networks" In-Reply-To: <20100203115343.A846B5459@berserkly.xs4all.nl> References: <20100203110001.3607.30612.Mailman@postboy.ripe.net> <20100203115343.A846B5459@berserkly.xs4all.nl> Message-ID: <20100203122032.GZ3692@Space.Net> Hi, On Wed, Feb 03, 2010 at 12:53:43PM +0100, Geert Jan de Groot wrote: > > If we use 192.168.1.0/24 for the RIPE meeting, and your corporate network > > at home uses 192.168.1.0/24 as well, most VPN clients will NOT be able > > to build a working connection. Try it. > > Given the number of attendees, the chances for address collisions with > > at least one participant's home network can be assumed to be near 100%. > > One workaround would be to have two (vastly different) 1918 prefixes > and giving people the possibility to switch (so, 2 SSID's, 2 prefixes, > say 192.168.224.0/20 and 10.210.32.0/20). Chances that someone will > conflict with both, are small. > > For better or worse, we will need to learn how to deal with this - We're dealing with this every day, outside of RIPE meetings. The RIPE meeting network is not a playground or experimental environment, but is there for the primary purpose that people who attend RIPE meetings can be able to contact their home networks in case something urgently need to be done there. With as little extra pain as possible. Having test networks in addition (!) to that is good. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 144438 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From leo.vegoda at icann.org Wed Feb 3 15:42:11 2010 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 3 Feb 2010 06:42:11 -0800 Subject: [ipv6-wg] RFC 1918 in "production networks" (was IPv6 experiments at future RIPE Meetings) In-Reply-To: <20100203090138.GP3692@Space.Net> References: <1A6DE1C92A2EE7ABF35B33C0@james-macbook-pro.ripe.net> <4B683C57.2000109@time-travellers.org> <20100202152148.GI3692@Space.Net> <4B684BAC.7010109@time-travellers.org> <20100202160748.GJ3692@Space.Net> <4B687264.3080909@burkov.aha.ru> <20100202203610.GK3692@Space.Net> <20100202234347.GF4736@nsn.com> <20100203090138.GP3692@Space.Net> Message-ID: On Feb 3, 2010, at 1:01 AM, Gert Doering wrote: > On Tue, Feb 02, 2010 at 04:20:55PM -0800, Leo Vegoda wrote: >>> But seriously, we will be living in this ugly world not long from now, >>> whether we like it or not. Why not try it out before it will be forced >>> on us? >> >> I agree with this statement. I think there is real value in >> experiencing the kinds of problems we are likely to see when the >> IPv4 address space has been fully allocated and further network >> growth cannot use unique IPv4 addresses. Having an optional CGN-style >> network to see what works and what needs to be improved would be >> genuinely useful. > > At the beginning of this thread, it was stated that the RIPE meeting > network is not to be treated as an experiment or testbed. Indeed. That's why I included the word "optional". Leo From mir at ripe.net Wed Feb 3 16:41:29 2010 From: mir at ripe.net (Mirjam Kuehne) Date: Wed, 03 Feb 2010 16:41:29 +0100 Subject: [ipv6-wg] How polluted is 1/8? Message-ID: <4B699929.90409@ripe.net> [Apologies for duplicates] Dear colleagues, After 1/8 was allocated to APNIC last week, the RIPE NCC did some measurements to find out how "polluted" this block really is. See some surprising results on RIPE Labs: http://labs.ripe.net/content/pollution-18 Please also note the call for feedback at the bottom of the article. Kind Regards, Mirjam Kuehne From marcoh at marcoh.net Wed Feb 3 19:13:38 2010 From: marcoh at marcoh.net (Marco Hogewoning) Date: Wed, 3 Feb 2010 19:13:38 +0100 Subject: [ipv6-wg] RFC 1918 in "production networks" (was IPv6 experiments at future RIPE Meetings) In-Reply-To: <4B686224.8050206@e4a.it> References: <1A6DE1C92A2EE7ABF35B33C0@james-macbook-pro.ripe.net> <4B683C57.2000109@time-travellers.org> <20100202152148.GI3692@Space.Net> <4B684BAC.7010109@time-travellers.org> <20100202160748.GJ3692@Space.Net> <4B686224.8050206@e4a.it> Message-ID: <43691BD6-8333-466F-BD27-74C7A0010D3D@marcoh.net> On 2 feb 2010, at 18:34, Riccardo Losselli wrote: > Hi, i must say i second Gert and Jan their position against the use of NAT, for pretty much the same stated reasons. Count me in, we should indeed consider the network as production and not do any experiments with it. I also wonder what we tend to prove to try and prove ourselves with that, the fact that NAT is evil and should not be used or are we going to make sure it works and show the world there is really nothing to worry about and there is no need to invest in IPv6 at all ? In either case, dping such at the ripe meeting is more or less a matter of preaching to the choir, most regular visitors should be already aware and if it's there first time we can probably convince them about the urgency without breaking our own connectivity. But maybe...there is a large group who is not aware, but those are usually not the folks visiting the RIPE meeting, but usually reside somewhere on the executive floor or stock market trading rooms. Why not instead of experimenting on our own come up with a bunch of usefull instructions to do-it-yourself, so people all over can use this is a tool to convince $boss that NAT is not a solution. Stuff I think is a 10 step instruction on how to limit the number of open tcp sessions on a box to some low number so they can experience for themselves those famous google maps pictures are for real and not something put together by the IPCC. MarcoH From david.kessens at nsn.com Wed Feb 3 23:44:05 2010 From: david.kessens at nsn.com (David Kessens) Date: Wed, 3 Feb 2010 14:44:05 -0800 Subject: [ipv6-wg] Discussion period for co-chair selection until 20100208 Message-ID: <20100203224405.GR4736@nsn.com> All, The call for candidates for co-chairs of the IPv6 working group has resulted in two candidates. See below for their names and a link to the mailing list with their motivations and plans for the working group: Shane Kerr http://www.ripe.net/ripe/maillists/archives/ipv6-wg/2010/msg00038.html Marco Hogewoning http://www.ripe.net/ripe/maillists/archives/ipv6-wg/2010/msg00041.html This brings us to the next step in our process: 1) The nominees are given a chance to determine whether they want to be considered or withdraw as they decided that there are other good candidates already available 2) The community may express opinions that could help the candidates to come to a decision on whether they want to be continued to be considered as a candidate - the community may consider appointing more than one co-chair in case of several good candidates Let's take until the end of Mon Feb 8, 2010 in a timezone of your choice to determine an outcome for both 1) and 2). I already have seen some discussion regarding point 2) and it leads me to believe that there is at least some support to appoint both candidates as co-chairs. Before making such a determination though, I would like to see a bit more discussion/comments, especially from people who have not taken a position yet on this topic. Basically, knowing our candidates, I would like to hear from you whether you prefer to appoint one or two co-chairs, and whether you have any preference for either candidate in case you believe one co-chair is enough. Note that this period is for open discussion and that it is perfectly fine to do alternate proposals. Our objective is to see if we can come to a consensus which allows us to avoid more complex ways of making a selection such as a vote. After our discussion period is over, I will determine if there is enough basis to do a Last Call to confirm a selection decision as determined from our discussion phase, or whether we perhaps need a bit more time for discussion or that we will have to resort to organizing a vote. I hope this helps, David Kessens --- From Fernando.Garcia at tecnocom.es Wed Feb 3 23:56:28 2010 From: Fernando.Garcia at tecnocom.es (=?iso-8859-1?Q?Garc=EDa_Fern=E1ndez=2C_Fernando?=) Date: Wed, 3 Feb 2010 23:56:28 +0100 Subject: [ipv6-wg] Discussion period for co-chair selection until 20100208 In-Reply-To: <20100203224405.GR4736@nsn.com> References: <20100203224405.GR4736@nsn.com> Message-ID: <98F2A3DA-F63B-457B-8CA2-352E974E0E7B@tecnocom.es> After reading their own introduction and knowing both candidates from several RIPE meetings, I give my support to both of them to be co-chairs. I think and odd number is good as break in discussions. El 03/02/2010, a las 23:44, David Kessens escribi?: > > All, > > The call for candidates for co-chairs of the IPv6 working group has > resulted in two candidates. See below for their names and a link to the > mailing list with their motivations and plans for the working group: > > Shane Kerr > http://www.ripe.net/ripe/maillists/archives/ipv6-wg/2010/msg00038.html > > Marco Hogewoning > http://www.ripe.net/ripe/maillists/archives/ipv6-wg/2010/msg00041.html > > This brings us to the next step in our process: > > 1) The nominees are given a chance to determine whether they want to > be considered or withdraw as they decided that there are other > good candidates already available > > 2) The community may express opinions that could help the > candidates to come to a decision on whether they want to > be continued to be considered as a candidate > - the community may consider appointing more than one co-chair > in case of several good candidates > > Let's take until the end of Mon Feb 8, 2010 in a timezone of your > choice to determine an outcome for both 1) and 2). > > I already have seen some discussion regarding point 2) and it leads me > to believe that there is at least some support to appoint both > candidates as co-chairs. > > Before making such a determination though, I would like to see a bit > more discussion/comments, especially from people who have not taken a > position yet on this topic. > > Basically, knowing our candidates, I would like to hear from you > whether you prefer to appoint one or two co-chairs, and whether you > have any preference for either candidate in case you believe one > co-chair is enough. > > Note that this period is for open discussion and that it is perfectly > fine to do alternate proposals. > > Our objective is to see if we can come to a consensus which allows us > to avoid more complex ways of making a selection such as a vote. > > After our discussion period is over, I will determine if there is > enough basis to do a Last Call to confirm a selection decision as > determined from our discussion phase, or whether we perhaps need a bit > more time for discussion or that we will have to resort to organizing > a vote. > > I hope this helps, > > David Kessens > --- > -- Tecnocom Fernando Garc?a Fern?ndez D.G. Integraci?n de Redes y Sistemas Josefa Valcarcel, 26 Edificio Merrimack III Madrid - 28027 Tel. Fijo: 901900900 ext 40383 Fax: (+34) 914313240 Tel. M?vil: (+34) 649428591 E-mail: fernando.garcia at tecnocom.es http://www.tecnocom.es From dogwallah at gmail.com Thu Feb 4 06:38:43 2010 From: dogwallah at gmail.com (McTim) Date: Thu, 4 Feb 2010 08:38:43 +0300 Subject: [ipv6-wg] Discussion period for co-chair selection until 20100208 In-Reply-To: <98F2A3DA-F63B-457B-8CA2-352E974E0E7B@tecnocom.es> References: <20100203224405.GR4736@nsn.com> <98F2A3DA-F63B-457B-8CA2-352E974E0E7B@tecnocom.es> Message-ID: 2010/2/4 Garc?a Fern?ndez, Fernando : > After reading their own introduction and knowing both candidates from several RIPE meetings, I give my support to both of them to be co-chairs. +1 -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel From DMenzulskiy at beeline.ru Thu Feb 4 08:20:06 2010 From: DMenzulskiy at beeline.ru (Dmitriy V Menzulskiy) Date: Thu, 4 Feb 2010 10:20:06 +0300 Subject: Ha: Re: [ipv6-wg] Discussion period for co-chair selection until 20100208 In-Reply-To: <98F2A3DA-F63B-457B-8CA2-352E974E0E7B@tecnocom.es> Message-ID: I agree with Fernando. WBR, Dmitry Menzulskiy, AKA DM3740-RIPE Garc?a Fern?ndez, Fernando "ipv6-wg at ripe.net" ??: ipv6-wg-admin at rip ????? e.net ???? Re: [ipv6-wg] Discussion period 04.02.2010 01:56 for co-chair selection until 20100208 After reading their own introduction and knowing both candidates from several RIPE meetings, I give my support to both of them to be co-chairs. I think and odd number is good as break in discussions. El 03/02/2010, a las 23:44, David Kessens escribi?: > > All, > > The call for candidates for co-chairs of the IPv6 working group has > resulted in two candidates. See below for their names and a link to the > mailing list with their motivations and plans for the working group: > > Shane Kerr > http://www.ripe.net/ripe/maillists/archives/ipv6-wg/2010/msg00038.html > > Marco Hogewoning > http://www.ripe.net/ripe/maillists/archives/ipv6-wg/2010/msg00041.html > > This brings us to the next step in our process: > > 1) The nominees are given a chance to determine whether they want to > be considered or withdraw as they decided that there are other > good candidates already available > > 2) The community may express opinions that could help the > candidates to come to a decision on whether they want to > be continued to be considered as a candidate > - the community may consider appointing more than one co-chair > in case of several good candidates > > Let's take until the end of Mon Feb 8, 2010 in a timezone of your > choice to determine an outcome for both 1) and 2). > > I already have seen some discussion regarding point 2) and it leads me > to believe that there is at least some support to appoint both > candidates as co-chairs. > > Before making such a determination though, I would like to see a bit > more discussion/comments, especially from people who have not taken a > position yet on this topic. > > Basically, knowing our candidates, I would like to hear from you > whether you prefer to appoint one or two co-chairs, and whether you > have any preference for either candidate in case you believe one > co-chair is enough. > > Note that this period is for open discussion and that it is perfectly > fine to do alternate proposals. > > Our objective is to see if we can come to a consensus which allows us > to avoid more complex ways of making a selection such as a vote. > > After our discussion period is over, I will determine if there is > enough basis to do a Last Call to confirm a selection decision as > determined from our discussion phase, or whether we perhaps need a bit > more time for discussion or that we will have to resort to organizing > a vote. > > I hope this helps, > > David Kessens > --- > -- Tecnocom Fernando Garc?a Fern?ndez D.G. Integraci?n de Redes y Sistemas Josefa Valcarcel, 26 Edificio Merrimack III Madrid - 28027 Tel. Fijo: 901900900 ext 40383 Fax: (+34) 914313240 Tel. M?vil: (+34) 649428591 E-mail: fernando.garcia at tecnocom.es http://www.tecnocom.es -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pic08182.gif Type: image/gif Size: 1255 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ecblank.gif Type: image/gif Size: 45 bytes Desc: not available URL: From jan at go6.si Thu Feb 4 08:48:50 2010 From: jan at go6.si (Jan Zorz @ go6.si) Date: Thu, 04 Feb 2010 08:48:50 +0100 Subject: [ipv6-wg] Discussion period for co-chair selection until 20100208 In-Reply-To: References: <20100203224405.GR4736@nsn.com> <98F2A3DA-F63B-457B-8CA2-352E974E0E7B@tecnocom.es> Message-ID: <4B6A7BE2.7090409@go6.si> McTim wrote: > 2010/2/4 Garc?a Fern?ndez, Fernando : >> After reading their own introduction and knowing both candidates from several RIPE meetings, I give my support to both of them to be co-chairs. > > > +1 > +1 Jan Zorz From us at sweet-sorrow.com Thu Feb 4 10:11:03 2010 From: us at sweet-sorrow.com (Us) Date: Thu, 04 Feb 2010 09:11:03 +0000 Subject: [ipv6-wg] Discussion period for co-chair selection until 20100208 In-Reply-To: <4B6A7BE2.7090409@go6.si> References: <20100203224405.GR4736@nsn.com> <98F2A3DA-F63B-457B-8CA2-352E974E0E7B@tecnocom.es> <4B6A7BE2.7090409@go6.si> Message-ID: <4B6A8F27.6020908@sweet-sorrow.com> On 02/04/2010 07:48, Jan Zorz @ go6.si wrote: > McTim wrote: >> 2010/2/4 Garc?a Fern?ndez, Fernando : >>> After reading their own introduction and knowing both candidates from >>> several RIPE meetings, I give my support to both of them to be >>> co-chairs. >> >> >> +1 >> > > +1 > > Jan Zorz > > I believe that is a great reasoning... Odd numbers are useful Ragnar Belial Us From chris at ripe.net Thu Feb 4 16:58:18 2010 From: chris at ripe.net (Chris Buckridge) Date: Thu, 4 Feb 2010 16:58:18 +0100 Subject: [ipv6-wg] IPv6 Act Now update Message-ID: Hi all, A couple of items from the IPv6 Act Now newsfeed over the last week that may be of interest: YouTube Turns On IPv6 support, Net Traffic Spikes (2 Feb 2010) Martin Millnert has already posted some useful information to the list on this subject. Google has quietly turned on IPv6 support for its YouTube video streaming Web site, which sent a spike of IPv6 traffic across the Internet. IPv6: the new platform (3 Feb 2010) Some perspectives on IPv6 deployment from India, the second largest telecom market in the world. The article includes discussion of the IPv6 survey done in the Asia Pacific recently by TNO/GNKS, who worked with the European Commission and the RIPE NCC on an IPv6 Deployment Monitoring Survey last year: Separate to IPv6 Act Now, the IPv6 adoption issue continues to gain exposure in the mainstream press. Dutch news site nu.nl ran an article this week based on the recent announcement from the NRO and ICANN that the pool of available IPv4 address space has reached 10%: [in Dutch] Regards, Chris Buckridge, RIPE NCC From Francis.Dupont at fdupont.fr Thu Feb 4 20:59:06 2010 From: Francis.Dupont at fdupont.fr (Francis Dupont) Date: Thu, 04 Feb 2010 19:59:06 +0000 Subject: [ipv6-wg] Re: RFC 1918 in "production networks" In-Reply-To: Your message of Wed, 03 Feb 2010 12:53:43 +0100. <20100203115343.A846B5459@berserkly.xs4all.nl> Message-ID: <201002041959.o14Jx6Ej068166@givry.fdupont.fr> I'd like to kill this private address collision issue: at the exception of some rare protocols designed to handle this case, the schema: private-address - NAT - Internet - NAT - private-address simply doesn't allow free communication between both end-points. So it doesn't matter the private addresses collide... Regards Francis.Dupont at fdupont.fr PS: note the key point is a private address is not routable in the Internet, i.e., you can change "private address" by "not routed" and all considerations still apply. From marc at let.de Thu Feb 4 21:20:30 2010 From: marc at let.de (Marc Manthey) Date: Thu, 4 Feb 2010 21:20:30 +0100 Subject: [ipv6-wg] Re: RFC 1918 in "production networks" In-Reply-To: <201002041959.o14Jx6Ej068166@givry.fdupont.fr> References: <201002041959.o14Jx6Ej068166@givry.fdupont.fr> Message-ID: Am 04.02.2010 um 20:59 schrieb Francis Dupont: > I'd like to kill this private address collision issue: at the > exception of some rare protocols designed to handle this case, > the schema: > private-address - NAT - Internet - NAT - private-address > simply doesn't allow free communication between both end-points. > So it doesn't matter the private addresses collide... > > Regards > > Francis.Dupont at fdupont.fr > > PS: note the key point is a private address is not routable in the > Internet, i.e., you can change "private address" by "not routed" > and all considerations still apply. +1 thanks Francis regards Marc -- Les enfants teribbles - research / deployment Marc Manthey- Vogelsangerstrasse 97 50823 K?ln - Germany Tel.:0049-221-29891489 Mobil:0049-1577-3329231 project : http://opencu.org blog: http://macbroadcast.org Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. From shane at time-travellers.org Fri Feb 5 01:02:18 2010 From: shane at time-travellers.org (Shane Kerr) Date: Fri, 05 Feb 2010 01:02:18 +0100 Subject: [ipv6-wg] Re: RFC 1918 in "production networks" In-Reply-To: <201002041959.o14Jx6Ej068166@givry.fdupont.fr> References: <201002041959.o14Jx6Ej068166@givry.fdupont.fr> Message-ID: <4B6B600A.2080704@time-travellers.org> Francis, On 2010-02-04 20:59, Francis Dupont wrote: > I'd like to kill this private address collision issue: at the > exception of some rare protocols designed to handle this case, > the schema: > private-address - NAT - Internet - NAT - private-address > simply doesn't allow free communication between both end-points. > So it doesn't matter the private addresses collide... The specific issue raised was for VPNs, so it's more like this: [ USER HERE ] private-address (VPN) - 10.0.0.1 private-address (conference network) - net 10.0.0.0/24 NAT (public-address) - 1.1.1.1 Internet - net 0.0.0.0/0 public-address - 1.2.3.4 private-address (VPN) - net 10.0.0.0/24 [ SUPER-SECRET CORPORATE NETWORK HERE ] Nobody terminates a VPN using a non-routable address, so that's not the issue. I think the issue is the collision of the RFC 1918 address space between the VPN and the local network for the user. As you see above, if the conference network and the VPN both use 10.0.0.0/24, communication gets... tricky. Well written VPN software can probably work around this in many cases, perhaps all, but I have no doubt there is a lot of poorly-written VPN software. :) Non-software solutions are using an IPv6 VPN (of course) or using public addresses for your VPN. Perhaps publicly-routable IPv4 addresses are easy for people on this list to get, but I am sure that is difficult for a lot of businesses. I wouldn't know how to do this if I had a small company of my own! -- Shane p.s. Note that 1.1.1.1 and 1.2.3.4 chosen as example addresses in honor of this research: http://labs.ripe.net/content/pollution-18 From dburk at burkov.aha.ru Fri Feb 5 06:30:00 2010 From: dburk at burkov.aha.ru (Dmitry Burkov) Date: Fri, 05 Feb 2010 08:30:00 +0300 Subject: [ipv6-wg] Re: RFC 1918 in "production networks" In-Reply-To: <4B6B600A.2080704@time-travellers.org> References: <201002041959.o14Jx6Ej068166@givry.fdupont.fr> <4B6B600A.2080704@time-travellers.org> Message-ID: <4B6BACD8.8000908@burkov.aha.ru> On 05.02.10 3:02, Shane Kerr wrote: > -- > Shane > > p.s. Note that 1.1.1.1 and 1.2.3.4 chosen as example addresses in honor > of this research: http://labs.ripe.net/content/pollution-18 > > Sorry - but all this discussion reminded me about current situation too (http://labs.ripe.net/content/pollution-18 ) Such vpn solution/services as h a m a c h i, etc (easily can be fpound) intensifely use 5/8, 1/8 and may be some others /8s. Dima From gert at space.net Fri Feb 5 08:44:34 2010 From: gert at space.net (Gert Doering) Date: Fri, 5 Feb 2010 08:44:34 +0100 Subject: [ipv6-wg] Re: RFC 1918 in "production networks" In-Reply-To: <4B6B600A.2080704@time-travellers.org> References: <201002041959.o14Jx6Ej068166@givry.fdupont.fr> <4B6B600A.2080704@time-travellers.org> Message-ID: <20100205074434.GP3692@Space.Net> Hi, On Fri, Feb 05, 2010 at 01:02:18AM +0100, Shane Kerr wrote: > Perhaps publicly-routable IPv4 addresses are easy for people on this > list to get, but I am sure that is difficult for a lot of businesses. > I wouldn't know how to do this if I had a small company of my own! Pick your ISP by different criteria than "who is offering the lowest price?". (Every ISP *could* assign public IPv4 addresses [according to RIPE policies, of course :-) ], but the larger mass-market ISPs usually don't do this, because evaluating network requests and handling RIPE documentation etc. costs money...) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 144438 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From sander at steffann.nl Fri Feb 5 10:36:04 2010 From: sander at steffann.nl (Sander Steffann) Date: Fri, 5 Feb 2010 10:36:04 +0100 Subject: [ipv6-wg] Discussion period for co-chair selection until 20100208 In-Reply-To: <98F2A3DA-F63B-457B-8CA2-352E974E0E7B@tecnocom.es> References: <20100203224405.GR4736@nsn.com> <98F2A3DA-F63B-457B-8CA2-352E974E0E7B@tecnocom.es> Message-ID: <397B560C-290A-43EE-B3C9-86CF3D80E131@steffann.nl> > After reading their own introduction and knowing both candidates from several RIPE meetings, I give my support to both of them to be co-chairs. I think and odd number is good as break in discussions. +1 Sander From spz at serpens.de Fri Feb 5 13:58:48 2010 From: spz at serpens.de (S.P.Zeidler) Date: Fri, 5 Feb 2010 13:58:48 +0100 Subject: [ipv6-wg] Re: RFC 1918 in "production networks" In-Reply-To: <20100205074434.GP3692@Space.Net> References: <201002041959.o14Jx6Ej068166@givry.fdupont.fr> <4B6B600A.2080704@time-travellers.org> <20100205074434.GP3692@Space.Net> Message-ID: <20100205125847.GI10255@serpens.de> Hi, Thus wrote Gert Doering (gert at space.net): > On Fri, Feb 05, 2010 at 01:02:18AM +0100, Shane Kerr wrote: > > Perhaps publicly-routable IPv4 addresses are easy for people on this > > list to get, but I am sure that is difficult for a lot of businesses. > > I wouldn't know how to do this if I had a small company of my own! > > Pick your ISP by different criteria than "who is offering the lowest price?". > > (Every ISP *could* assign public IPv4 addresses [according to RIPE policies, > of course :-) ], but the larger mass-market ISPs usually don't do this, > because evaluating network requests and handling RIPE documentation etc. > costs money...) Even the larger mass-market ISPs will give you a range if you pick a business contract instead of a residential private user one. As to what you do when you are a small business is simple: you pick a local range that is different than what your phone company uses, and tell your "road warrior" people to use their data plan in a fix, resp renumber your 5 internal servers and DHCP range if it collides with a partners' network range. You can do -that- very easily over a weekend. It gets a lot more interesting for large companies (much harder to renumber) connecting to other large companies. There not only is double NAT, which is bad enough in a static setting, there's the crawling horror of having someone tell you "oh you can get the necessary info by soap from 10.9.8.7" and you get a merry game of finding out which 10.9.8.7 they were referring to, how it is natted, how your server is natted (and whether both are natted the right way, ie not as client on a collective address but on their own addresses), and making sure the firewalls in the path open to the right addresses for that segment of the path (add fun: have six different departments controlling routers, firewalls and servers). I can't wait to have globally unique addresses everywhere. regards, spz -- spz at serpens.de (S.P.Zeidler) From marcoh at marcoh.net Fri Feb 5 20:55:20 2010 From: marcoh at marcoh.net (Marco Hogewoning) Date: Fri, 5 Feb 2010 20:55:20 +0100 Subject: [ipv6-wg] Discussion period for co-chair selection until 20100208 In-Reply-To: <20100203224405.GR4736@nsn.com> References: <20100203224405.GR4736@nsn.com> Message-ID: <0ADEDFA3-7732-4DB5-9DC5-BC155E697C3E@marcoh.net> On 3 feb 2010, at 23:44, David Kessens wrote: > Basically, knowing our candidates, I would like to hear from you > whether you prefer to appoint one or two co-chairs, and whether you > have any preference for either candidate in case you believe one > co-chair is enough. Hi All, I had a short chat with Shane this afternoon and we would like you to know we as candidated would prefer the option to appoint two co-chairs. Shane and I have known eachother for quite some time and our goals and objectives for the future of the IPv6 working group are the same, we both are looking forward working with David and the community to live up to the new charter en make IPv6 a succes. Thanks for all the support so far, MarcoH and Shane From LHOFFMAN at bouyguestelecom.fr Sat Feb 6 13:46:44 2010 From: LHOFFMAN at bouyguestelecom.fr (HOFFMANN, Lionel) Date: Sat, 6 Feb 2010 13:46:44 +0100 Subject: [ipv6-wg] Discussion period for co-chair selection until 20100208 In-Reply-To: <20100203224405.GR4736@nsn.com> References: <20100203224405.GR4736@nsn.com> Message-ID: OK +1 for me Lionel HOFFMANN Direction Technique Tel: 01 39 45 42 76 Mob: 06 60 31 42 76 Email: lhoffman at bouyguestelecom.fr Adresse: Centre d'affaires La Boursidiere RN186 92355 LE PLESSIS ROBINSON cedex -----Message d'origine----- De : ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] De la part de David Kessens Envoy? : mercredi 3 f?vrier 2010 23:44 ? : ipv6-wg at ripe.net Objet : [ipv6-wg] Discussion period for co-chair selection until 20100208 All, The call for candidates for co-chairs of the IPv6 working group has resulted in two candidates. See below for their names and a link to the mailing list with their motivations and plans for the working group: Shane Kerr http://www.ripe.net/ripe/maillists/archives/ipv6-wg/2010/msg00038.html Marco Hogewoning http://www.ripe.net/ripe/maillists/archives/ipv6-wg/2010/msg00041.html This brings us to the next step in our process: 1) The nominees are given a chance to determine whether they want to be considered or withdraw as they decided that there are other good candidates already available 2) The community may express opinions that could help the candidates to come to a decision on whether they want to be continued to be considered as a candidate - the community may consider appointing more than one co-chair in case of several good candidates Let's take until the end of Mon Feb 8, 2010 in a timezone of your choice to determine an outcome for both 1) and 2). I already have seen some discussion regarding point 2) and it leads me to believe that there is at least some support to appoint both candidates as co-chairs. Before making such a determination though, I would like to see a bit more discussion/comments, especially from people who have not taken a position yet on this topic. Basically, knowing our candidates, I would like to hear from you whether you prefer to appoint one or two co-chairs, and whether you have any preference for either candidate in case you believe one co-chair is enough. Note that this period is for open discussion and that it is perfectly fine to do alternate proposals. Our objective is to see if we can come to a consensus which allows us to avoid more complex ways of making a selection such as a vote. After our discussion period is over, I will determine if there is enough basis to do a Last Call to confirm a selection decision as determined from our discussion phase, or whether we perhaps need a bit more time for discussion or that we will have to resort to organizing a vote. I hope this helps, David Kessens --- L'int?grit? de ce message n'?tant pas assur?e sur internet, la soci?t? exp?ditrice ne peut ?tre tenue responsable de son contenu ni de ses pi?ces jointes. Toute utilisation ou diffusion non autoris?e est interdite. Si vous n'?tes pas destinataire de ce message, merci de le d?truire et d'avertir l'exp?diteur. The integrity of this message cannot be guaranteed on the Internet. The company that sent this message cannot therefore be held liable for its content nor attachments. Any unauthorized use or dissemination is prohibited. If you are not the intended recipient of this message, then please delete it and notify the sender. From Francis.Dupont at fdupont.fr Sat Feb 6 14:29:50 2010 From: Francis.Dupont at fdupont.fr (Francis Dupont) Date: Sat, 06 Feb 2010 13:29:50 +0000 Subject: [ipv6-wg] Re: RFC 1918 in "production networks" In-Reply-To: Your message of Fri, 05 Feb 2010 01:02:18 +0100. <4B6B600A.2080704@time-travellers.org> Message-ID: <201002061329.o16DToUA020293@givry.fdupont.fr> In your previous mail you wrote: The specific issue raised was for VPNs, so it's more like this: => it is not th standard VPN case but a particular case named the road warrior VPN. Fortunately for obvious security reasons the routing system is in general fully overwritten to disallow "local" communications so the address collision is not an issue. p.s. Note that 1.1.1.1 and 1.2.3.4 chosen as example addresses in honor of this research: http://labs.ripe.net/content/pollution-18 => I saw that: funny (if you have no prefix in 1.0.0.0/8). Thanks Francis.Dupont at fdupont.fr From ralph.smit at rasm.nl Sun Feb 7 21:08:09 2010 From: ralph.smit at rasm.nl (Ralph Smit) Date: Sun, 07 Feb 2010 21:08:09 +0100 Subject: [ipv6-wg] Discussion period for co-chair selection until 20100208 In-Reply-To: <4B6F1C8D.5090002@xs4all.nl> References: <4B6F1C8D.5090002@xs4all.nl> Message-ID: <4B6F1DA9.60401@rasm.nl> Marco Hogewoning wrote: > On 3 feb 2010, at 23:44, David Kessens wrote: > >> Basically, knowing our candidates, I would like to hear from you >> whether you prefer to appoint one or two co-chairs, and whether you >> have any preference for either candidate in case you believe one >> co-chair is enough. > > > Hi All, > > I had a short chat with Shane this afternoon and we would like you to > know we as candidated would prefer the option to appoint two co-chairs. > Shane and I have known eachother for quite some time and our goals and > objectives for the future of the IPv6 working group are the same, we > both are looking forward working with David and the community to live up > to the new charter en make IPv6 a succes. > > Thanks for all the support so far, > > MarcoH and Shane > > > I support both candidates and agree with many who replied before me (and the candidates themselves) that 2 co-chairs would be a good idea. Regards, Ralph Smit. From Ragnar.Anfinsen at altibox.no Mon Feb 8 10:36:59 2010 From: Ragnar.Anfinsen at altibox.no (Anfinsen, Ragnar) Date: Mon, 8 Feb 2010 10:36:59 +0100 Subject: [ipv6-wg] Discussion period for co-chair selection until 20100208 In-Reply-To: <4B6F1DA9.60401@rasm.nl> References: <4B6F1C8D.5090002@xs4all.nl> <4B6F1DA9.60401@rasm.nl> Message-ID: > I support both candidates and agree with many who replied before me (and > the candidates themselves) that 2 co-chairs would be a good idea. > > Regards, > > Ralph Smit. +1 for both candidates. Best Regards? Ragnar Anfinsen Altibos AS > -----Opprinnelig melding----- > Fra: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] P? vegne av Ralph > Smit > Sendt: 7. februar 2010 21:08 > Til: ipv6-wg at ripe.net > Emne: Re: [ipv6-wg] Discussion period for co-chair selection until 20100208 > > Marco Hogewoning wrote: > > On 3 feb 2010, at 23:44, David Kessens wrote: > > > >> Basically, knowing our candidates, I would like to hear from you > >> whether you prefer to appoint one or two co-chairs, and whether you > >> have any preference for either candidate in case you believe one > >> co-chair is enough. > > > > > > Hi All, > > > > I had a short chat with Shane this afternoon and we would like you to > > know we as candidated would prefer the option to appoint two co-chairs. > > Shane and I have known eachother for quite some time and our goals and > > objectives for the future of the IPv6 working group are the same, we > > both are looking forward working with David and the community to live up > > to the new charter en make IPv6 a succes. > > > > Thanks for all the support so far, > > > > MarcoH and Shane > > > > > > > > I support both candidates and agree with many who replied before me (and > the candidates themselves) that 2 co-chairs would be a good idea. > > Regards, > > Ralph Smit. From dave.wilson at heanet.ie Mon Feb 8 11:11:09 2010 From: dave.wilson at heanet.ie (Dave Wilson) Date: Mon, 08 Feb 2010 10:11:09 +0000 Subject: [ipv6-wg] IPv6 experiments at future RIPE Meetings In-Reply-To: <4B6847E7.2000403@dialtelecom.cz> References: <1A6DE1C92A2EE7ABF35B33C0@james-macbook-pro.ripe.net> <4B6847E7.2000403@dialtelecom.cz> Message-ID: <4B6FE33D.9070000@heanet.ie> Hi all, > I see plain IPv6 without any kind of IPv4 support including protocol > translation as very nice idea there. People could see how much (or how > few if I would like to be accurate and/or sarcastic) of public and their > own private services like their SSH, POP3, SMTP or IM accounts could be > reached by IPv6. It could be also a motivation for a lot of people to > make more services v6 available *before* the meeting. I see a lot of v6 > enabled networks but only a small amount of v6 enabled services. This is a good point, but I find myself with a competing requirement. One of the parts of my company's IPv4 depletion strategy is to make a service where a new customer can connect with IPv6 only, but still access the whole internet in some way, including the IPv4 part. I think that this is one of the most important and least developed parts of the technology, and we have few enough opportunities to see it tested. All the best, Dave -- Dave Wilson, Senior Network Engineer HEAnet Limited, Ireland's Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin 1 Registered in Ireland, no 275301 tel: +353-1-660 9040 fax: +353-1-660 3666 web: http://www.heanet.ie/ H323 GDS:0035301101738 PGP: 1024D/C757ADA9 From kzorba at otenet.gr Mon Feb 8 13:45:50 2010 From: kzorba at otenet.gr (Kostas Zorbadelos) Date: Mon, 8 Feb 2010 14:45:50 +0200 Subject: [ipv6-wg] Discussion period for co-chair selection until 20100208 In-Reply-To: <20100203224405.GR4736@nsn.com> References: <20100203224405.GR4736@nsn.com> Message-ID: <201002081445.51070.kzorba@otenet.gr> On Thursday 04 February 2010 00:44:05 David Kessens wrote: Hello all, as a relatively newcomer to this community, I would like to learn more about the duties and responsibilities of a WG [co]chair. As I understand it, the appointment procedures are quite informal with all the merits and shortcomings that come with it. Having said this, I have the impression that 3 people are better than one or two. I have met both candidates, read their comments for the WG and I support them both. I also think it would be a good idea for other people to come forward as well. The migration to IPv6 needs all the effort and support it can get, having active and expanding WG / forums such as this. Regards, Kostas Zorbadelos > > I already have seen some discussion regarding point 2) and it leads me > to believe that there is at least some support to appoint both > candidates as co-chairs. > > Before making such a determination though, I would like to see a bit > more discussion/comments, especially from people who have not taken a > position yet on this topic. > > Basically, knowing our candidates, I would like to hear from you > whether you prefer to appoint one or two co-chairs, and whether you > have any preference for either candidate in case you believe one > co-chair is enough. > > --- From marc.blanchet at viagenie.ca Mon Feb 8 21:58:50 2010 From: marc.blanchet at viagenie.ca (Marc Blanchet) Date: Mon, 08 Feb 2010 15:58:50 -0500 Subject: [ipv6-wg] announcing DNS64-NAT64 opensource implementations Message-ID: <4B707B0A.5030208@viagenie.ca> This is to announce the availability of two NAT64-DNS64 open-source implementations by Viagenie, as follows: ====== NAT64 ====== BSD PF: this implementation of NAT64 is made by modifying the PF packet filter available on BSD systems. A new 'nat64' statement is created in the pf.conf file to enable the nat64 functionality. Linux Netfilter: The implementation of NAT64 for linux is available as a kernel module. It uses Netfilter's facilities for packet interception. The configuration is done with parameters provided at module insertion. ====== DNS64 ====== As announced in july 2009 during IETF Stockholm, the companion DNS64 functionality is also available in two implementations, as follows: BIND: this implementation of DNS64 is made by modifying the BIND DNS server. A new "dns64-prefix" statement in options is created in the named.conf file to enable DNS64 functionality. Unbound: this implementation of DNS64 is made by adding a module to the Unbound DNS server. To enable the DNS64 functionality, the module should be declared and the dns64-prefix statement should be added in the unbound.conf file. The two functionalities (NAT64 and DNS64) make a complete system for translating IPv6-IPv4 packets. The source code, some pre-compiled packages and project description are available at: http://ecdysis.viagenie.ca. This project was funded by NLNet foundation and Viagenie. We are looking for feedback, patches, suggestions from the community. http://ecdysis.viagenie.ca Regards, Marc Blanchet, Simon Perreault, Jean-Philippe Dionne Viagenie From david.kessens at nsn.com Wed Feb 10 01:12:23 2010 From: david.kessens at nsn.com (David Kessens) Date: Tue, 9 Feb 2010 16:12:23 -0800 Subject: [ipv6-wg] Approval of the minutes for wg session RIPE 59 In-Reply-To: <20100129063800.GB2654@nsn.com> References: <20100129063800.GB2654@nsn.com> Message-ID: <20100210001222.GA27386@nsn.com> The deadline for objections regarding the minutes has now passed. We have received one request from Sander for a correction (http://ripe.net/ripe/maillists/archives/ipv6-wg/2010/msg00048.html). I will consider the minutes now final except for the correction that I will work out with Sander and the minute taker using the sound recording. I don't believe that there is much value in doing an additional call for approval of this correction as the comment was about the timelines of the new charter and we already have achieved that milestone. Let me know if you have a problem with this. David Kessens --- On Thu, Jan 28, 2010 at 10:38:01PM -0800, ext David Kessens wrote: > > Please find below the minutes from the IPv6 WG session at RIPE 59. > > The minutes will be declared final if no objections, except for minor > editorial corrections that will be fixed before publication, will be > received by the end of Sunday February 7, 2010 in a timezone of your > choice. > > Finally, I would like to thank Alex Band for the excellent minutes! > > Thanks, > > David Kessens > --- > > RIPE Meeting: 59 > Working Group: IPv6 > Chair: David Kessens > Date: Tuesday October 6, 2009, 16:00-18:00 > > David welcomed the attendees and opened the session. > > A. Administrative Matters > > o Welcome > o Select scribe: Alex Band > o Select Jabber Monitor: Rumy Kanis > o Finalize agenda > o Approval of minutes from previous working group meeting > > B. RIPE NCC IPv6 Update > James Aldridge, RIPE NCC > http://www.ripe.net/ripe/meetings/ripe-59/presentations/aldridge-ncc-update-v6.pdf > > There were no questions. > > C. Future of the Working Group: Charter Discussion > Shane Kerr, David Kessens. Input from the audience > http://www.ripe.net/ripe/meetings/ripe-59/presentations/kessens-v6-wg-future.pdf > > Shane mentioned that the initial idea for an IPv6 Working Group > came from looking at the statistics Geoff Huston publishes. "Make IPv6 > Happen", was the summary of the charter of the WG. Most of the > discussion on IPv6 is actually in the Address Policy WG, so he proposed > to shut down the WG and move on to a bigger and better thing. > > David asked the audience for input. > > Olaf Kolkman (NLNetlabs) asked how the activities of the WG tied into > the IPv6ActNow website. > > Shane said that there is not really any tie in, and that he thought that > is was a shame that something like IPv6ActNow is necessary at all. > > Rob Blokzijl (RIPE Chair) mentioned that the message that is coming > out of the WG is heard by the community at large, however, it doesn't > seem to be received and digested by the industry on a wide scale. He > proposed that the WG is not shut down, because there is important work > to be done, especially in the coming two years and when IPv4 has run out. > > Gert Doering (Spacenet) commented that the WG is not the place where > people go nowadays to learn about IPv6. At the RIPE Meeting, those kinds > of discussions are held in the Plenary. > > Rob gave an example: there were two presentations about the > general implementations of IPv6 at customer premises. In one case, the > CPE worked fine, in the other it didn't. He would have liked to have > seen a technical presentation in the IPv6 WG session on why that is. > > Shane responded there are definitely opportunities for the WG in that > capacity, and even other topics related to IPv6, like Multi-layer NAT. > > Denesh Babutha (Aexiomus//Cyberstrider) agreed that the WG had reached > the end of its useful life as originally envisaged. He said that, as > such, the WG needs to evolve, and he thought that this needed to happen > through the the charter. Denesh added that the WG needed to move away > from repeating the IPv6 situation in every single meeting and move onto > more useful discussions. The new charter should be inclusive of other > industry areas too. > > David said that there were many topics covered by the WG that were not > originally in the charter. > > Bernard Tuy said that there is an enormous need for technical training > and that kind of knowledge can come from the WG. > > David asked the audience how to move forward with the WG and whether it > should continue in it's current form? > > Ruediger Volk (Deutsche Telekom) commented that the current form seems > to be "quasi-plenary". > > Rob commented that the WG should be modest in its aims and not try to > reach the end goal without some intermediate steps. He said that the WG > should focus on real world implementations. > > Shane commented that the WG did not need to come up with a new charter > here and now. > > Rob proposed that a new draft charter is written. > > David summarized the feedback for a new charter as more focus on > education and outreach activities. > > Maarten Botterman said that not all of those activities have to be > within the WG. > > David asked the audience if preparing for a hybrid IPv4/IPv6 world > should be part of the charter. > > Rob commented that outreach should lie with the RIPE NCC efforts, such > as the IPv6ActNow initiative. He said that training is a sensitive issue > because the RIPE NCC does not want to compete with its members. > > Rumy Kanis (RIPE NCC Training Services Manager) commented that the RIPE > NCC offers IPv6 training, but careful steps were taken to ensure the > RIPE NCC does not compete with the membership. > > Marco Wertejuk (Binconsult) said that he believes the focus for the new > charter should be "how to encourage conservation of IPv4 and deployment > of IPv6". > > David said that he assessed from the audience feedback that there isn't > much support for the WG to focus on non-technical outreach activities. > David asked Rob for a time line. > > Rob said that the WG should take things slowly, and propose a new > charter at the next RIPE Meeting and that further discussions should > continue on the mailing list. > > D. Future RIPE Network Experiments - David Kessens. Input from the audience > > David asked the audience if there was further interest in IPv6 > network experiments during a RIPE Meeting. > > Gert said that forcing IPv6 on people is actually a good idea. He said > we should even go as far as making the RIPE Meeting network IPv6 only > for the whole week. He added that we should do the experiment without > NAT-PT. > > David said that he would like to see a completely new experiment. > > Marco Hogewoning (XS4all) said that although IPv6 connectivity in > general is good, tunneling is needed in some places in order to get full > connectivity. > > David Wilson (HEAnet) said that the IPv6 hour should be repeated, and > that the WG should get new experiences because things have changed since > the last time it was done. > > Izumi from JPNIC that for their experiments, they created different > testbeds for different kinds of implementations. > > David asked the audience if the IPv6 Hour should be rerun at future > meetings.. There is consensus that it should be. > > E. IPv6 Deployment: What are the Remaining Issues and Bottlenecks? - A > panel discussion with interactive input from the audience. Moderator: > Maarten Botterman, GNKS Consult > > http://www.ripe.net/ripe/meetings/ripe-59/presentations/botterman-towards-v6-deployment.pdf > > > Gert Doering introduced himself and asked the question "What kind of > Internet do we want to have in five years?". > > Geoff Huston introduced himself and in a slide set proposed the question > "Is the IPv6 transition an example of market failure?" > http://www.ripe.net/ripe/meetings/ripe-59/presentations/huston-ipv6-transition.pdf > > Kurtis Lindqvist introduced himself and explained his own experiences > with IPv6 deployment. He said that doing a slow and gradual > implementation has been very beneficial. > > Maarten Botterman did a live survey, with the question "What would you > gain by postponing, and what would you gain by stepping up to the plate, > earlier rather than later?". 40 votes were cast, most go to: > > o By stepping up to the plate I have time and space to do the > transition, which will allow me to do it gradually and well thought through > > o By stepping up to the plate I confirm my brand's image as > 'state-of-the-art' or 'top-of-the-wave' > > Geoff commented that the respondents are most likely non-representative. > > Gert said that he is not surprised with the numbers. > > Kurtis said that looking at the responses, he is optimistic. > > Maarten said that some people responded with 'none of the above'. He > asked three of those people to comment: > > Ruediger said that for all of the relevant players there is still enough > time for doing a proper job. > > Bernard said that there was no vendor support, so ISPs will never start > until that happens. > > Jan Hugo Prins said that there will never be end user demand. Deployment > is not picking up because of security issues. > > Geoff reiterated that he thought that the situation we are finding > ourselves in right now is no accident. It is in many companies' > interests to delay IPv6 adoption. > > Shane agreed with Geoff. > > Gabriella Paolini (GARR) said that the biggest issue is that middleware > doesn't support IPv6 and that changes very slowly. > > Maarten did another live survey with the following question: "There is > perception and experience of/with a number of hurdles that seem to be > difficult to overcome. Which are important to you?". > > o As there is very little customer demand, I cannot justify the > investment to my management, even if I would like to move > > o I have the experience that my vendors cannot deliver what I need > > o None of the above (highest score) > > Ruediger said that the options are very extreme. Slow and gradual > deployment is a real option. > > Geoff commented that in his days at a telco, the biggest cost turned out > to be customer support. IPv6 could become expensive in that respect > with end users calling in because of issues. > > Maarten asked people to comment: > > - Wilfried Woeber (Vienna University) commented that he would have to > select 'none of the above' for all questions. His issue is that the > questions are too black or white. The biggest problem from his point of > view is in layer 7 or 8: infrastructure, applications etc. The backbone > has been done for years. > > - Marco said that he agreed with Geoff, the cost is not in the hardware. > IPv6 is not a product, don't pay extra for it. > > - An attendee said that in a lot of cases, even though the product spec > sheet says that IPv6 is supported, there is no feature parity with IPv4. > > Gert said he agreed with most of the comments. > > Geoff said that any vendor is willing to give you what you want, as long > as you put down the money. > > Kurtis added that there was also a big push from vendors for MPLS. > > Marco added that some IPv6 functionality used to be free, but after > vendors realized that there was a market for it, they started charging > for a license. > > Maarten did another live survey, the results with the most votes were: > > o The deployment of IPv6 is unavoidable for my organization in due time > > o Technically, everything is in place to deploy IPv6 > > Geoff commented that openness is the key in the end. IPv6 is the only > way to guarantee that. > > Kurtis added that he was surprised that so many people responded "I will > deploy in due time", because that is pretty close. > > Geoff re-stated that the market is well informed, and that this > situation is intentional in order to maximize shareholder profits at > large corporations. > > Ruediger agreed that the industry is flooded with information. But he > asked how enlightened are people? > > Geoff responded that it's all about vendor lock in. > > Brian Nisbet (HEAnet) said that the WG keeps having the same discussion > meeting after meeting. He said that he could not believe that people are > not well informed. > > Kurtis said that CFO's cannot be convinced of the urgency of something > that will happen two years from now. An attendee said that for mobile > operators, the vendors of mobile terminals are the blockers. > > Maarten showed the results of the last survey. The panel shared some > closing thoughts. The general thought was that the community should stop > distributing messaging, and start moving packets. > > Maarten closed the discussion. > > F. Developments/Initiatives Regarding IPv6 in the RIPE Region and Beyond > - Input from the audience > > No input was given. > > Y. Input for the RIPE NCC Activity Plan - Input from the audience > > No input was given. > > Z. AOB > > None. > > David closed the session. > > --------- David Kessens --- From david.kessens at nsn.com Wed Feb 10 01:28:04 2010 From: david.kessens at nsn.com (David Kessens) Date: Tue, 9 Feb 2010 16:28:04 -0800 Subject: [ipv6-wg] Last Call: Confirmation of co-chairs (20100217) Message-ID: <20100210002804.GC18940@nsn.com> The discussion phase regarding new co-chair positions has now ended. It seems that there is strong support to appoint: Shane Kerr http://www.ripe.net/ripe/maillists/archives/ipv6-wg/2010/msg00038.html Marco Hogewoning http://www.ripe.net/ripe/maillists/archives/ipv6-wg/2010/msg00041.html as additional co-chairs for the ipv6 working group. Please let us know if you have objections to such a solution by the end of Wed Feb 17, 2010 in a time zone of your choice. There is no need to restate your supportive position again as there was already a significant number of people that expressed support for this approach. Thanks, David Kessens --- From david.kessens at nsn.com Wed Feb 10 01:36:50 2010 From: david.kessens at nsn.com (David Kessens) Date: Tue, 9 Feb 2010 16:36:50 -0800 Subject: [ipv6-wg] Discussion period for co-chair selection until 20100208 In-Reply-To: <201002081445.51070.kzorba@otenet.gr> References: <20100203224405.GR4736@nsn.com> <201002081445.51070.kzorba@otenet.gr> Message-ID: <20100210003649.GD18940@nsn.com> Kostas, On Mon, Feb 08, 2010 at 02:45:50PM +0200, Kostas Zorbadelos wrote: > > as a relatively newcomer to this community, I would like to learn more about > the duties and responsibilities of a WG [co]chair. Please see below in the attached draft document for co-chair responsibilities. Note that this a draft document that contains some known issues and is here and there out of date but it should give you an idea on what co-chairs are supposed to do. Let me know if you have any questions, David Kessens --- Version: 2.4: May 19 2009 Working Group Chair Job Description 1) Introduction The purpose of this document is to describe the role, responsibility and expectations associated with RIPE Working Group (WG) Chairs. The document is divided into the following sections: - WG Chairs and Co-Chairs - Creating WG Charters - Updating WG charters - Policy Development Process (PDP) Responsibilities - RIPE Meeting Responsibilities 2) Working Group Chairs and Co-Chairs WG Chairs and Co-Chairs should always make it clear whether they speak on behalf of themselves, the organisations they work for or the WG for which they are Chair or Co-Chair. RIPE WGs have two different ways of dividing up the responsibilities of the WG Chair(s): WG Chair Model and Equal Co-Chair Model. The model that is used depends upon the specific needs, history and set-up of a particular WG. i) WG Chair Model In this model, a WG Chair has overall responsibility for the WG and can be supported by Co-Chairs. These Co-Chairs can assist with general WG support and can deputise for the WG Chair if he/she is not able to attend a RIPE Meeting. ii) Equal Co-Chair Model In this model, the Co-Chairs share the responsibility for PDP and RIPE Meeting activities. The Co-Chairs act together to make any formal statements (for example on policy development) that are relevant to their WG. For each RIPE Meeting, one of the Co-Chairs serves as the primary contact for the WG and for session organisational matters. 3) Creating Working Group Charters i) Working Group Created from a Task Force A WG usually emerges from a Task Force. In this case, the procedure for creating the WG Charter is as follows: The head of the Task Force creates the Charter for the new WG in consultation with other members of the Task Force. Once this has been agreed, and approved by the RIPE Chair, the Charter for the new WG is officially recognised. ii) New Working Group Emerging from an Existing WG If a new WG emerges from an existing WG then the Charter for the new WG should be drawn up by the Chairs and Co-Chairs of the new and existing WG. Once this has been agreed, and approved by the RIPE Chair, the Charter for the new WG is officially recognised. 4) Updating Working Group Charters If a WG Chair needs to update the WG charter, he/she needs to have the text approved by the WG Co-Chairs before presenting the revised charter to the WG for their approval via the WG mailing list and/or at a RIPE Meeting. 5) Policy Development Process (PDP) Responsibilities WG Chairs are expected to: - Stay up-to-date with all phases of a policy proposal relevant to their WG - Follow discussions on the relevant WG mailing list(s) - Guide mailing list discussions as appropriate - Take charge of PDP milestone decisions relevant to their WG - Ensure PDP milestone decisions keep to the timeframe as described in the RIPE PDP Document - Make a collective, final decision supported by a reasonable level of awareness as to whether a particular policy proposal has received consensus - Inform the RIPE NCC when a policy proposal has received consensus and should become a RIPE Document Note - In a WG with an equal Co-Chair model (see 2(i)), these responsibilities are shared between the Co-Chairs. 6) RIPE Meetings Responsibilities i) General/Plenary WG Chairs are expected to: - Attend RIPE Meetings or send a Co-Chair as their deputy - Help develop the RIPE Meeting Plenary Agenda through the mailing list - Lead a Plenary session as agreed in advance of the meeting and pass on any action points that are decided in this Plenary session to the relevant WG Note - In a WG with an equal Co-Chair model (see 2(i)), these responsibilities are shared between the Co-Chairs. ii) Working Group Specific WG Chairs are expected to: - Solicit relevant presentations for the WG session - Post a draft agenda for their WG session (at least 2-3 weeks before a RIPE Meeting where possible) - Lead the WG session and encourage active participation - Present a short summary (including actions and highlights) from their WG in the closing Plenary session at the RIPE Meeting - Review and approve the minutes from their WG session (4 - 6 weeks-) - Attend WG Chair lunches during RIPE Meetings - Attend WG Chair meetings between RIPE Meetings - Update the action list of their WG after the RIPE Meeting Note - In a WG with an equal Co-Chair model (see 2(i)), one Co-Chair takes overall responsibility for these activities at a particular RIPE Meeting. --- From sander at steffann.nl Wed Feb 10 10:02:50 2010 From: sander at steffann.nl (Sander Steffann) Date: Wed, 10 Feb 2010 10:02:50 +0100 (CET) Subject: [ipv6-wg] Approval of the minutes for wg session RIPE 59 In-Reply-To: <20100210001222.GA27386@nsn.com> References: <20100129063800.GB2654@nsn.com> <20100210001222.GA27386@nsn.com> Message-ID: <3005.80.101.103.96.1265792570.squirrel@webmail.sintact.nl> Hi David, > I don't believe that there is much value in doing an additional call > for approval of this correction as the comment was about the timelines > of the new charter and we already have achieved that milestone. Let me > know if you have a problem with this. Not at all. Sander From pveijk at gmail.com Thu Feb 11 15:31:14 2010 From: pveijk at gmail.com (Peter van Eijk) Date: Thu, 11 Feb 2010 15:31:14 +0100 Subject: [ipv6-wg] Youtube over IPv6! Message-ID: <2f8e201c1002110631k7074b0a8q50ddb0703b907ca7@mail.gmail.com> A couple of days ago Martin Milnert wrote The time when it began is clearly visible in our own IPv6 graphs, http://stats.csbnet.se/public/ipv6/csbnet-ipv6-traffictypes.html , and you can see similar correlated data at for example http://www.de-cix.net/content/network.html . What puzzles me is that we see none of this at the AMS-IX, have a look at http://www.ams-ix.net/sflow-stats/ipv6/ Does anybody have a clue as to why that is? Peter van Eijk (dutch IPv6 taskforce) From neufeind at gmx.de Thu Feb 11 16:13:04 2010 From: neufeind at gmx.de (Stefan Neufeind) Date: Thu, 11 Feb 2010 16:13:04 +0100 Subject: [ipv6-wg] Youtube over IPv6! In-Reply-To: <2f8e201c1002110631k7074b0a8q50ddb0703b907ca7@mail.gmail.com> References: <2f8e201c1002110631k7074b0a8q50ddb0703b907ca7@mail.gmail.com> Message-ID: <4B741E80.6020302@gmx.de> On 02/11/2010 03:31 PM, Peter van Eijk wrote: > A couple of days ago Martin Milnert wrote > > > The time when it began is clearly visible in our own IPv6 graphs, > http://stats.csbnet.se/public/ipv6/csbnet-ipv6-traffictypes.html , > and you can see similar correlated data at for example > http://www.de-cix.net/content/network.html . > > > What puzzles me is that we see none of this at the AMS-IX, have a look > at http://www.ams-ix.net/sflow-stats/ipv6/ > > Does anybody have a clue as to why that is? Hi Peter, IPv6 amount on AMS-IX is simply too high (afaik mainly news-traffic etc. nowadays) to reflect the additional YouTube-IPv6-traffic. Kind regards, Stefan Neufeind From marcoh at marcoh.net Thu Feb 11 16:46:07 2010 From: marcoh at marcoh.net (Marco Hogewoning) Date: Thu, 11 Feb 2010 16:46:07 +0100 Subject: [ipv6-wg] Youtube over IPv6! In-Reply-To: <2f8e201c1002110631k7074b0a8q50ddb0703b907ca7@mail.gmail.com> References: <2f8e201c1002110631k7074b0a8q50ddb0703b907ca7@mail.gmail.com> Message-ID: <44A10BF8-08B0-4297-844A-C1DCCFEB7203@marcoh.net> On 11 feb 2010, at 15:31, Peter van Eijk wrote: > A couple of days ago Martin Milnert wrote > > > The time when it began is clearly visible in our own IPv6 graphs, > http://stats.csbnet.se/public/ipv6/csbnet-ipv6-traffictypes.html , > and you can see similar correlated data at for example > http://www.de-cix.net/content/network.html . > > > What puzzles me is that we see none of this at the AMS-IX, have a look > at http://www.ams-ix.net/sflow-stats/ipv6/ > > Does anybody have a clue as to why that is? > > Peter van Eijk > (dutch IPv6 taskforce) > I can think of various reasons: - scale The CBS graph show an increase of a few megabit, that won't show up in graphs at gigabit level. - It only works for selected parties It's hard to tell which networks actually have their nameservers whitelisted by google, I know a few who do...I can probably also find a number of bigger ones in NL who don't. - Routing preference A lot of traffic is based around a few tunnel operators and another part is 6to4 anycast. It might just be that route selection happens to decide the path over DECIX is preferred to a path over Amsterdam. It might also be that Amsterdam traffic happens to be on a private interconnect instead of the shared medium. - Local situation We know France has a relatively high number of IPv6 users, I have seen sources which indicate the same goes for Russia. It might be that those parties involved are only situated in Frankfurt and not in Amsterdam. And I'm not going to open the can of worms labeled 'sampling interval'. So graphs and especially the public ones don't necessarely reflect reality, the only way to be 100% sure is to get to the graphs on the end points. We normally don't publish statistics and I won't do now, but I can tell you the impact of youtube got lost in the day to day lump of usenet trraffic we see passing on our interfaces. MarcoH From chrisb at ripe.net Thu Feb 11 17:31:46 2010 From: chrisb at ripe.net (Chris Buckridge) Date: Thu, 11 Feb 2010 17:31:46 +0100 Subject: [ipv6-wg] IPv6 Act Now: News Update Message-ID: <9973A747-7F8D-4348-A315-751F6C7154CE@ripe.net> Hi all, A couple of news items from the IPv6 Act Now newsfeed over the last week that might be of interest: First accreditation issued for testing to US IPv6 product specs (9 Feb 2010) Amid all the discussion of government leading the way on IPv6 through procurement, news from the US that the University of New Hampshire's test lab is among the first wave of labs to be accredited to test networking products for compliance with government IPv6 specifications. AfriNIC embraces Internet challenges in Africa (8 Feb 2010) An extensive interview with AfriNIC CEO Adiel Akplogan, discussing the challenges facing the region's Internet community and some of the new roles AfriNIC is taking on, including working with law enforcement agencies and participating in the Africa Union heads of state summit. Pakistan needs to shift to Internet Protocol Version 6 (9 Feb 2010) IPv6 makes it into the Pakistani press, with the IPv6 Monitory Group of Pakistan Telecommunication Authority (PTA) making a number of recommendations for the widespread adoption of IPv6 in the country (including establishing a National Internet Registry). Regards, Chris Buckridge, RIPE NCC -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1724 bytes Desc: not available URL: From millnert at csbnet.se Fri Feb 12 01:07:16 2010 From: millnert at csbnet.se (Martin Millnert) Date: Fri, 12 Feb 2010 01:07:16 +0100 Subject: [ipv6-wg] Youtube over IPv6! In-Reply-To: <44A10BF8-08B0-4297-844A-C1DCCFEB7203@marcoh.net> References: <2f8e201c1002110631k7074b0a8q50ddb0703b907ca7@mail.gmail.com> <44A10BF8-08B0-4297-844A-C1DCCFEB7203@marcoh.net> Message-ID: <1265933236.5147.48.camel@hsa.vpn.anti> On Thu, 2010-02-11 at 16:46 +0100, Marco Hogewoning wrote: > The CBS graph show an increase of a few megabit, that won't show up in > graphs at gigabit level. Our graph is IMHO quite appropriate for an eyeball-only leaf network, as that is what we are. Even if we only have a meager 2000 customers, an *extremely* high percentage of these are IPv6-enabled (much due to a very high turnover rate, meaning new students with new capable OS's move in frequently). We are way past 50% of our users IPv6 enabled by now. So, for the eyeball side of it all, and if you are whitelisted, I would wager that the increase seen in our graph is ~quite representative of what type of impact it can have in a (even dormitory) network with high IPv6-stack ratio. Having said that, there wasn't much to see on v6 before. And most peer to peer connections still carry most data over v4. This is something I suspect 2010 might see heavy change of though. Stay alert and be prepared to relay! > So graphs and especially the public ones don't necessarely reflect > reality, the only way to be 100% sure is to get to the graphs on the > end points. I'm well aware 1000-1500 IPv6 clients isn't much of a statistical base on the full Internet scale... so, more data would be interesting, including such from Google. Cheers, -- Martin Millnert -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From kzorba at otenet.gr Fri Feb 12 10:04:44 2010 From: kzorba at otenet.gr (Kostas Zorbadelos) Date: Fri, 12 Feb 2010 11:04:44 +0200 Subject: [ipv6-wg] Discussion period for co-chair selection until 20100208 In-Reply-To: <20100210003649.GD18940@nsn.com> References: <20100203224405.GR4736@nsn.com> <201002081445.51070.kzorba@otenet.gr> <20100210003649.GD18940@nsn.com> Message-ID: <201002121104.44523.kzorba@otenet.gr> On Wednesday 10 February 2010 02:36:50 David Kessens wrote: Thank you David, nice work. Is this document part of a work in progress that will eventually be published somewhere? Documents like these can help newcomers understand how RIPE WG communities operate and also add to the openness of these forums. Regards, Kostas > Kostas, > > On Mon, Feb 08, 2010 at 02:45:50PM +0200, Kostas Zorbadelos wrote: > > as a relatively newcomer to this community, I would like to learn more > > about the duties and responsibilities of a WG [co]chair. > > Please see below in the attached draft document for co-chair > responsibilities. Note that this a draft document that contains some > known issues and is here and there out of date but it should give you > an idea on what co-chairs are supposed to do. > > Let me know if you have any questions, > > David Kessens > --- > > Version: 2.4: May 19 2009 > > Working Group Chair Job Description ... From vegard at svanberg.no Fri Feb 12 11:10:21 2010 From: vegard at svanberg.no (Vegard Svanberg) Date: Fri, 12 Feb 2010 11:10:21 +0100 Subject: [ipv6-wg] /127 for point to point links Message-ID: <20100212101021.GW4538@svanberg.no> Hello. We've stumbled across a problem with a router manufacturer, which won't implement support for /127 prefix lengths. Now, we do have peering/transit partners using /127 on their p2p links. The result is that we either cannot peer with them, or will have to get new routers. RFC 3627 states that /127 is considered harmful, however I do feel this RFC confuse people since it doesn't propose a definite solution. It suggests a number of solutions and indicates using /64 is the right thing. I must say I strongly disagree on that conclusion. Wasting so much address space on point to point links just makes no sense to me. So I'm not sure what to do here. I have to convince someone; either our partners or the router manufacturer. I have the impression that /127 is used widely out there. -- Vegard Svanberg [*Takapa at IRC (EFnet)] From us at sweet-sorrow.com Fri Feb 12 12:23:42 2010 From: us at sweet-sorrow.com (Us) Date: Fri, 12 Feb 2010 11:23:42 +0000 Subject: [ipv6-wg] /127 for point to point links In-Reply-To: <20100212101021.GW4538@svanberg.no> References: <20100212101021.GW4538@svanberg.no> Message-ID: <4B753A3E.3010209@sweet-sorrow.com> On 02/12/2010 10:10, Vegard Svanberg wrote: > Hello. We've stumbled across a problem with a router manufacturer, which > won't implement support for /127 prefix lengths. Now, we do have > peering/transit partners using /127 on their p2p links. The result is > that we either cannot peer with them, or will have to get new routers. > > RFC 3627 states that /127 is considered harmful, however I do feel this > RFC confuse people since it doesn't propose a definite solution. It > suggests a number of solutions and indicates using /64 is the right > thing. I must say I strongly disagree on that conclusion. Wasting so > much address space on point to point links just makes no sense to me. > > So I'm not sure what to do here. I have to convince someone; either our > partners or the router manufacturer. I have the impression that /127 is > used widely out there. > Well, personaly as being the first commecial ipv6 provider in our country I had the same reservations. But after a talk with our IPv6 experts (go6.si) I/we just accepted the fact that we're wasting perfectly good address space and we just put /64 on P2P links... Still, if it becomes an obvious overkill I'm quite sure that by that time the HW manufacturers will have things sorted out. And that the "powers to be" will define the standards. Ragnar Belial Us From vegard at svanberg.no Fri Feb 12 11:43:45 2010 From: vegard at svanberg.no (Vegard Svanberg) Date: Fri, 12 Feb 2010 11:43:45 +0100 Subject: [ipv6-wg] /127 for point to point links In-Reply-To: <62E36FB0-73A5-443E-8B27-3B8A728F8105@ripe.net> References: <20100212101021.GW4538@svanberg.no> <62E36FB0-73A5-443E-8B27-3B8A728F8105@ripe.net> Message-ID: <20100212104345.GB4538@svanberg.no> * Chris Buckridge [2010-02-12 11:36]: > Thanks for your email. I would suggest that you send your question > to the RIPE IPv6 Working Group mailing list - you can subscribe > here: Uh, I did, didn't I? -- Vegard Svanberg [*Takapa at IRC (EFnet)] From peter at digitalinfrastructures.nl Fri Feb 12 11:03:05 2010 From: peter at digitalinfrastructures.nl (Peter van Eijk) Date: Fri, 12 Feb 2010 11:03:05 +0100 Subject: [ipv6-wg] Youtube over IPv6! In-Reply-To: <1265933236.5147.48.camel@hsa.vpn.anti> References: <2f8e201c1002110631k7074b0a8q50ddb0703b907ca7@mail.gmail.com> <44A10BF8-08B0-4297-844A-C1DCCFEB7203@marcoh.net> <1265933236.5147.48.camel@hsa.vpn.anti> Message-ID: <001101caabca$92707ef0$b7517cd0$@nl> Interesting discussion, and some new hypotheses. I am doing some research on the side to figure out how to best measure IPv6 progress. >From the quantitative angle, the size of your network hardly matters. A six fold increase (sic) is still a six fold increase. At CSBnet is goes from 1 Mbit/sec to 6 Mbit (roughly), at DE-CIX it goes from 0.3 Gbit to 1.8 Gbit. More interesting is the IPv6 fraction. At DE-CIX this has risen six fold to 0.16% of total traffic (roughly), while at the AMS-IX it is steady at 0.17%. As the total traffic levels at these exchanges are comparable (around 0.6 Terabit/sec avg) I have the idea that we need two hypotheses. As Marco suggests the AMS-IX may have traditionally carried a lot of IPv6 netnews, which explains its early lead. My other hypothesis is that the youtube traffic is privately peered outside of the amsix statistic, because Google has datacenters in the Netherlands (I have other research to support that). Martin, could you comment on your current IPv6 fraction? In all cases, daily patterns suggest that home users are dominant, even before Youtube got on IPv6. Anyone to comment on these ideas? Regards. Peter van Eijk, +31 6 22684939, peter @ digitalinfrastructures.nl -----Original Message----- From: Martin Millnert [mailto:millnert at csbnet.se] Sent: vrijdag 12 februari 2010 1:07 To: Marco Hogewoning Cc: Peter van Eijk; ipv6-wg at ripe.net Subject: Re: [ipv6-wg] Youtube over IPv6! On Thu, 2010-02-11 at 16:46 +0100, Marco Hogewoning wrote: > The CBS graph show an increase of a few megabit, that won't show up in > graphs at gigabit level. Our graph is IMHO quite appropriate for an eyeball-only leaf network, as that is what we are. Even if we only have a meager 2000 customers, an *extremely* high percentage of these are IPv6-enabled (much due to a very high turnover rate, meaning new students with new capable OS's move in frequently). We are way past 50% of our users IPv6 enabled by now. So, for the eyeball side of it all, and if you are whitelisted, I would wager that the increase seen in our graph is ~quite representative of what type of impact it can have in a (even dormitory) network with high IPv6-stack ratio. Having said that, there wasn't much to see on v6 before. And most peer to peer connections still carry most data over v4. This is something I suspect 2010 might see heavy change of though. Stay alert and be prepared to relay! > So graphs and especially the public ones don't necessarely reflect > reality, the only way to be 100% sure is to get to the graphs on the > end points. I'm well aware 1000-1500 IPv6 clients isn't much of a statistical base on the full Internet scale... so, more data would be interesting, including such from Google. Cheers, -- Martin Millnert From ot at cisco.com Fri Feb 12 11:52:26 2010 From: ot at cisco.com (Ole Troan) Date: Fri, 12 Feb 2010 11:52:26 +0100 Subject: [ipv6-wg] /127 for point to point links In-Reply-To: <20100212101021.GW4538@svanberg.no> References: <20100212101021.GW4538@svanberg.no> Message-ID: Vegard, > Hello. We've stumbled across a problem with a router manufacturer, which > won't implement support for /127 prefix lengths. Now, we do have > peering/transit partners using /127 on their p2p links. The result is > that we either cannot peer with them, or will have to get new routers. > > RFC 3627 states that /127 is considered harmful, however I do feel this > RFC confuse people since it doesn't propose a definite solution. It > suggests a number of solutions and indicates using /64 is the right > thing. I must say I strongly disagree on that conclusion. Wasting so > much address space on point to point links just makes no sense to me. > > So I'm not sure what to do here. I have to convince someone; either our > partners or the router manufacturer. I have the impression that /127 is > used widely out there. let's be clear that you are not wasting address space by using a /64 on a point to point link. IPv6 address space is as close to an infinite resource when it comes to the number of /64s. a point to point link uses 2 addresses out of 2^64 a random multi-access link doesn't use a significantly larger proportion in any case. the argument for using /127 is for example that there is no confusion what the address on the other end is. or that you will have no problem with looping to unassigned addresses within the prefix. if you have an implementation which doesn't support /127 you can just use a /128 on each end. cheers, Ole From pekkas at netcore.fi Fri Feb 12 11:35:54 2010 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 12 Feb 2010 12:35:54 +0200 (EET) Subject: [ipv6-wg] /127 for point to point links In-Reply-To: <20100212101021.GW4538@svanberg.no> References: <20100212101021.GW4538@svanberg.no> Message-ID: On Fri, 12 Feb 2010, Vegard Svanberg wrote: > Hello. We've stumbled across a problem with a router manufacturer, which > won't implement support for /127 prefix lengths. Now, we do have > peering/transit partners using /127 on their p2p links. The result is > that we either cannot peer with them, or will have to get new routers. > > RFC 3627 states that /127 is considered harmful, however I do feel this > RFC confuse people since it doesn't propose a definite solution. It > suggests a number of solutions and indicates using /64 is the right > thing. I must say I strongly disagree on that conclusion. Wasting so > much address space on point to point links just makes no sense to me. The argument about wasting address space is not useful. However, there are other arguments for using /127, especially if you're using e.g. SDH technology (the interface is "point-to-point" media). http://tools.ietf.org/html/draft-kohno-ipv6-prefixlen-p2p-00 describes these to some degree. (The draft is being revised.) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From marcoh at marcoh.net Fri Feb 12 12:13:35 2010 From: marcoh at marcoh.net (Marco Hogewoning) Date: Fri, 12 Feb 2010 12:13:35 +0100 Subject: [ipv6-wg] Youtube over IPv6! In-Reply-To: <001101caabca$92707ef0$b7517cd0$@nl> References: <2f8e201c1002110631k7074b0a8q50ddb0703b907ca7@mail.gmail.com> <44A10BF8-08B0-4297-844A-C1DCCFEB7203@marcoh.net> <1265933236.5147.48.camel@hsa.vpn.anti> <001101caabca$92707ef0$b7517cd0$@nl> Message-ID: On 12 feb 2010, at 11:03, Peter van Eijk wrote: > Interesting discussion, and some new hypotheses. > I am doing some research on the side to figure out how to best measure IPv6 progress. > > From the quantitative angle, the size of your network hardly matters. A six fold increase (sic) is still a six fold increase. At CSBnet is goes from 1 Mbit/sec to 6 Mbit (roughly), at DE-CIX it goes from 0.3 Gbit to 1.8 Gbit. > > More interesting is the IPv6 fraction. At DE-CIX this has risen six fold to 0.16% of total traffic (roughly), while at the AMS-IX it is steady at 0.17%. > > As the total traffic levels at these exchanges are comparable (around 0.6 Terabit/sec avg) I have the idea that we need two hypotheses. > As Marco suggests the AMS-IX may have traditionally carried a lot of IPv6 netnews, which explains its early lead. My other hypothesis is that the youtube traffic is privately peered outside of the amsix statistic, because Google has datacenters in the Netherlands (I have other research to support that). Hypothesis 3: 2002::/16 is routed as one block, now this is anycast but it's highly likely _all_ traffic for this block coming from one datacenter ends up at the same path, given the distance between AMS and FRA I don't think much people would care where it ends up. And yes a sixfold is a sixfold but it greatly depends on user behavior. Youtube is interactive, so it causes traffic burst, normally these would flatten out against other users, but with low numbers of users these spikes all of a sudden do show up. Next to that youtube only needs a very limited amount of bandwidth compared to other protocols such as usenet and p2p who are happy to eat away whatever they can. Martin reports he has around 1000 ~ 1500 customers, our tunnelbox shows similair numbers. His traffic is a couple of megabits, our box rarely drops below 100 mbit/s. Now I'm not making any judgement who is better or has a bigger one, but it clearly shows that it is not as straighforward as one may think. I happen to have a usenet box in my network which is on IPv6, thousands of residential users will take care of the rest. I guess the youtube traffic is there, it must be there, but I haven't seen any. Even on my own link at home it won't show up because those little peaks on the graphs get blown away by other traffic and since I'm the only user I know which is which :) If you want measurements, measure at the end points that is the only reliable method. Make sure everybody measures the same, using the same set of counters (either byte counters or flow sampling) or find a way to correct your data between the 2. Make sure averages, peaks and other oddities are represented in the same way and based on the same time interval or make sure to correct for these as well. Keep in mind not everybody has the same view of the world, especially since one of the bigger IPv6 content sources only returns AAAA to selected parties, others like ourselves don't run dual stack at all, the published address for our usenet box is A only, the v6 hostname is published in other places aimed at people who know what they are doing or looking for. And the list goes on and on, for instance due to OS weirdness (or shall I say brokenness) probably half of the traffic I could get over IPv6 comes in over IPv4, this solely relies on whatever DNS query returns first. Accoording to reports on nanog, DECNIC just stopped responding to queries from 6to4 hosts, this might show a drop again in the German graphs. Now don't get me wrong, I like statistics but please make sure they are correct and even more important make sure to draw the correct conclusions from them and don't have people shopping for the results what they want to see. Google just made another great leap forward by dual stacking youtube, but it's still a very small step for mankind. Maybe, trying again to avoid opening the can labeled 'sample interval', we as a group can try and come up with a model on how to measure IPv6 deployment: Should we look at the public graphs and if so, how can we correct these figures to actually be meaningfull ? Or are we better of measuring at the end points and how are we going to convince people to share their numbers ? What makes a better representation of the situation, the amount if traffic or the number of hosts actually being dual stacked ? Should we consider all traffic or look specific protocols ? I personally think we should look at numbers of hosts, how big a percentage of the users have IPv6 (native/6rd/tunnel/6to4) and how man hosts are out there who have both A and AAAA records asociated (and you might want to test for *.ipv6 and www6 as well). Traffic figures are nice but don't mean anything, if you take a close look at the AMSIX history you will find at least 2 occasions where you see a significant drop in v6 traffic, one only lasted about a day and was caused by 2 usenet providers having trouble at the same time. The other one lasted for months and was due to 1(!) usenet feed being moved back from v6 to v4 causing traffic to drop from 0.1 % to 0.0 % again. I've seen that graph show up in a number of publications. In the end we can expect the v4 world to keep on working, for me the big question to answer is "how far are we in making sure the any to any model will survive after we ran out", if by that date I still have 80% of my traffic on IPv4 I won't care, as long as my users can access every and each service they wish for and at the same time somebody who only has an IPv6 address is still able to communicate with my users and can access all of my and my customers' services. MarcoH From mohacsi at niif.hu Fri Feb 12 12:11:13 2010 From: mohacsi at niif.hu (Mohacsi Janos) Date: Fri, 12 Feb 2010 12:11:13 +0100 (CET) Subject: [ipv6-wg] /127 for point to point links In-Reply-To: <20100212101021.GW4538@svanberg.no> References: <20100212101021.GW4538@svanberg.no> Message-ID: On Fri, 12 Feb 2010, Vegard Svanberg wrote: > Hello. We've stumbled across a problem with a router manufacturer, which > won't implement support for /127 prefix lengths. Now, we do have > peering/transit partners using /127 on their p2p links. The result is > that we either cannot peer with them, or will have to get new routers. > > RFC 3627 states that /127 is considered harmful, however I do feel this > RFC confuse people since it doesn't propose a definite solution. It > suggests a number of solutions and indicates using /64 is the right > thing. I must say I strongly disagree on that conclusion. Wasting so > much address space on point to point links just makes no sense to me. > > So I'm not sure what to do here. I have to convince someone; either our > partners or the router manufacturer. I have the impression that /127 is > used widely out there. RFC 3627 is informational RFC. Does not describe any strict rules. Read the RFC and understand /127 is harmful only in certain cases: poin-to-point link + usage of subnet anycast. Other problems might exist as described in section 5. Also Have a look at: http://www.ietf.org/id/draft-kohno-ipv6-prefixlen-p2p-00.txt Janos Mohacsi Head of HBONE+ project Network Engineer, Deputy Director of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 From gert at space.net Fri Feb 12 12:25:13 2010 From: gert at space.net (Gert Doering) Date: Fri, 12 Feb 2010 12:25:13 +0100 Subject: [ipv6-wg] Youtube over IPv6! In-Reply-To: References: <2f8e201c1002110631k7074b0a8q50ddb0703b907ca7@mail.gmail.com> <44A10BF8-08B0-4297-844A-C1DCCFEB7203@marcoh.net> <1265933236.5147.48.camel@hsa.vpn.anti> <001101caabca$92707ef0$b7517cd0$@nl> Message-ID: <20100212112513.GA3692@Space.Net> Hi, On Fri, Feb 12, 2010 at 12:13:35PM +0100, Marco Hogewoning wrote: > And the list goes on and on, for instance due to OS weirdness (or > shall I say brokenness) probably half of the traffic I could get > over IPv6 comes in over IPv4, this solely relies on whatever DNS > query returns first. Accoording to reports on nanog, DECNIC just > stopped responding to queries from 6to4 hosts, this might show a > drop again in the German graphs. Would that be "DENIC"? If yes, can you point me to the Nanog article? (Since we're providing IPv6 transit to DENIC, it might be a problem with our 6to4 relay - or with their routing. They're multihomed, they make their own mistakes^Wdecisions...) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 144438 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From millnert at csbnet.se Fri Feb 12 12:31:19 2010 From: millnert at csbnet.se (Martin Millnert) Date: Fri, 12 Feb 2010 12:31:19 +0100 Subject: [ipv6-wg] /127 for point to point links In-Reply-To: <4B753A3E.3010209@sweet-sorrow.com> References: <20100212101021.GW4538@svanberg.no> <4B753A3E.3010209@sweet-sorrow.com> Message-ID: <1265974279.15157.19.camel@desktop2.mgn> On Fri, 2010-02-12 at 11:23 +0000, Us wrote: > Well, personaly as being the first commecial ipv6 provider in our > country I had the same reservations. But after a talk with our IPv6 > experts (go6.si) I/we just accepted the fact that we're wasting > perfectly good address space and we just put /64 on P2P links... Even though others have said that the argument of wasting space isn't useful and that the number of 64s is near infinite, I wanted to show just how :) If you've heard it before, stop reading this mail now. We're using an 1/8th of the IPv6 space this first attempt to do it, or 2001::/3. There are maybe 5 more usable eights in case we screw this up. If some ~9 billion people on this planet *each* used say 16x /64 links, the total usage for this would only amount to a /27, or a 1/2^24th of the 2001::/3 space. A whopping 6 micro-percents, or 0.000006%. 64:s are built to be unique per broadcast domain. In the technologies I am aware of today (which arguably are few), none creates a "broadcast domain scaling problem" by for example connecting each user to every other user on always unique broadcast domains -- THIS would not scale! So the "address space waste" argument for todays network models is void, but there might very well, as Pekka exemplifies, be other technical/engineering constraints that come in to play. Regards, -- Martin Millnert -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From marcoh at marcoh.net Fri Feb 12 13:01:50 2010 From: marcoh at marcoh.net (Marco Hogewoning) Date: Fri, 12 Feb 2010 13:01:50 +0100 Subject: [ipv6-wg] Youtube over IPv6! In-Reply-To: <20100212112513.GA3692@Space.Net> References: <2f8e201c1002110631k7074b0a8q50ddb0703b907ca7@mail.gmail.com> <44A10BF8-08B0-4297-844A-C1DCCFEB7203@marcoh.net> <1265933236.5147.48.camel@hsa.vpn.anti> <001101caabca$92707ef0$b7517cd0$@nl> <20100212112513.GA3692@Space.Net> Message-ID: <9355CC9B-8BB4-4B5B-BBF0-A1491E9DF886@marcoh.net> On 12 feb 2010, at 12:25, Gert Doering wrote: > Hi, > > On Fri, Feb 12, 2010 at 12:13:35PM +0100, Marco Hogewoning wrote: >> And the list goes on and on, for instance due to OS weirdness (or >> shall I say brokenness) probably half of the traffic I could get >> over IPv6 comes in over IPv4, this solely relies on whatever DNS >> query returns first. Accoording to reports on nanog, DECNIC just >> stopped responding to queries from 6to4 hosts, this might show a >> drop again in the German graphs. > > Would that be "DENIC"? If yes, can you point me to the Nanog article? Yeah, sorry for the typo: http://mailman.nanog.org/pipermail/nanog/2010-February/018162.html > (Since we're providing IPv6 transit to DENIC, it might be a problem with > our 6to4 relay - or with their routing. They're multihomed, they make > their own mistakes^Wdecisions...) Love to hear if in fact this is policy or simply a technical issue and bad translation from a service representative. MarcoH From millnert at csbnet.se Fri Feb 12 13:10:15 2010 From: millnert at csbnet.se (Martin Millnert) Date: Fri, 12 Feb 2010 13:10:15 +0100 Subject: [ipv6-wg] Youtube over IPv6! In-Reply-To: References: <2f8e201c1002110631k7074b0a8q50ddb0703b907ca7@mail.gmail.com> <44A10BF8-08B0-4297-844A-C1DCCFEB7203@marcoh.net> <1265933236.5147.48.camel@hsa.vpn.anti> <001101caabca$92707ef0$b7517cd0$@nl> Message-ID: <1265976615.15157.56.camel@desktop2.mgn> On Fri, 2010-02-12 at 12:13 +0100, Marco Hogewoning wrote: > I guess the youtube traffic is there, it must be there, but I haven't > seen any. Even on my own link at home it won't show up because those > little peaks on the graphs get blown away by other traffic and since > I'm the only user I know which is which :) > > If you want measurements, measure at the end points that is the only > reliable method. Make sure everybody measures the same, using the same > set of counters (either byte counters or flow sampling) or find a way > to correct your data between the 2. Well, as you say, we really don't have to overly complicate this wrt. Youtube IP traffic. I doubt anybody will argue that eyeballs have traffic to Google/Youtube traffic. How much? I remember some flow sample statistics from a few years back here from Gothenburg, covering some ~10k students with plenty of bandwidth. I assume these _swedish students_ knew how to use P2P. :) Google+Youtube was about 3rd or 4th unique origin AS by bytes transferred! I don't have the references available, but this I personally consider a ~fact for eyeball networks, at least in Scandinavia. Prove me wrong. :) I don't remember what this meant in terms of fraction of the total traffic, but I suspect somewhere around 5-10%? If what we want to find out is % IPv6 traffic out of all IP traffic, and how this might change by some large players, or protocols, (suddenly) changing behaviour, this is relevant. I assume the ranking of Google/Youtube has dropped much since then. More data needed. I could write more, but where I want to come basically boils down to that I strongly suspect that the current IPv6 support infrastructure for the transition mechanisms today do not support a Google/Youtube ceasing to use the DNS resolver whitelist method as a connectivity quality assurance technique. And I believe we will have to cope with the transition mechanisms for quite a while. We're a long way from native IPv6 to a majority of Internet users. But OS:s support transition and this is being "rolled out" every day, everywhere. So, the operator community should IMO continue to do more to help the transition. What would happen if $LARGE_FRACTION of p2p traffic suddenly moved to v6 transitions? This can happen. So it is, like you say Marco, not very significant how many % traffic there is today. There are much more important aspects to look at. I fully agree with you on this. Basically what to follow closely, I think boils down to something like: * users type of v6 connectivity, if at all * changes to p2p * changes to ~top-10 CDN:ish networks (youtube included) * rest of the web in general There are plenty previous work done in following/measuring several of these points. Would be nice with some potaroo.net type, stable, place to follow it, though. Regards, -- Martin Millnert -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From Skeeve at eintellego.net Fri Feb 12 12:54:36 2010 From: Skeeve at eintellego.net (Skeeve Stevens) Date: Fri, 12 Feb 2010 22:54:36 +1100 Subject: [ipv6-wg] /127 for point to point links In-Reply-To: <20100212101021.GW4538@svanberg.no> References: <20100212101021.GW4538@svanberg.no> Message-ID: <292AF25E62B8894C921B893B53A19D973972CBD89F@BUSINESSEX.business.ad> Generally here we're using /112's for P2P links.... ...Skeeve -- Skeeve Stevens, CEO/Technical Director eintellego Pty Ltd - The Networking Specialists skeeve at eintellego.net / www.eintellego.net Phone: 1300 753 383, Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 / skype://skeeve www.linkedin.com/in/skeeve ; facebook.com/eintellego -- NOC, NOC, who's there? > -----Original Message----- > From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf > Of Vegard Svanberg > Sent: Friday, 12 February 2010 9:10 PM > To: ipv6-wg at ripe.net > Subject: [ipv6-wg] /127 for point to point links > > Hello. We've stumbled across a problem with a router manufacturer, > which > won't implement support for /127 prefix lengths. Now, we do have > peering/transit partners using /127 on their p2p links. The result is > that we either cannot peer with them, or will have to get new routers. > > RFC 3627 states that /127 is considered harmful, however I do feel this > RFC confuse people since it doesn't propose a definite solution. It > suggests a number of solutions and indicates using /64 is the right > thing. I must say I strongly disagree on that conclusion. Wasting so > much address space on point to point links just makes no sense to me. > > So I'm not sure what to do here. I have to convince someone; either our > partners or the router manufacturer. I have the impression that /127 is > used widely out there. > > -- > Vegard Svanberg [*Takapa at IRC (EFnet)] From mir at ripe.net Fri Feb 12 14:47:19 2010 From: mir at ripe.net (Mirjam Kuehne) Date: Fri, 12 Feb 2010 14:47:19 +0100 Subject: [ipv6-wg] Youtube over IPv6! Message-ID: <4B755BE7.4090301@ripe.net> Dear all, Martin Millnert wrote: > > There are plenty previous work done in following/measuring several of > > these points. Would be nice with some potaroo.net type, stable, place to > > follow it, though. > I am not sure this is exactly what you were looking for: On RIPE Labs we published a list of IPv6 measurements various people are doing: http://labs.ripe.net/content/ipv6-measurements-compilation It also lists to potaroo, RIS, CAIDA and a lot more. We are currently working on a follow-up article listing data and statistics we found in the meantime. If you are aware of other measurements related to IPv6, we'd be happy to include them. Kind Regards, Mirjam K?hne RIPE NCC From gert at space.net Fri Feb 12 15:00:05 2010 From: gert at space.net (Gert Doering) Date: Fri, 12 Feb 2010 15:00:05 +0100 Subject: [ipv6-wg] Youtube over IPv6! In-Reply-To: <9355CC9B-8BB4-4B5B-BBF0-A1491E9DF886@marcoh.net> References: <2f8e201c1002110631k7074b0a8q50ddb0703b907ca7@mail.gmail.com> <44A10BF8-08B0-4297-844A-C1DCCFEB7203@marcoh.net> <1265933236.5147.48.camel@hsa.vpn.anti> <001101caabca$92707ef0$b7517cd0$@nl> <20100212112513.GA3692@Space.Net> <9355CC9B-8BB4-4B5B-BBF0-A1491E9DF886@marcoh.net> Message-ID: <20100212140005.GE3692@Space.Net> Hi, On Fri, Feb 12, 2010 at 01:01:50PM +0100, Marco Hogewoning wrote: > On 12 feb 2010, at 12:25, Gert Doering wrote: > > > On Fri, Feb 12, 2010 at 12:13:35PM +0100, Marco Hogewoning wrote: > >> And the list goes on and on, for instance due to OS weirdness (or > >> shall I say brokenness) probably half of the traffic I could get > >> over IPv6 comes in over IPv4, this solely relies on whatever DNS > >> query returns first. Accoording to reports on nanog, DECNIC just > >> stopped responding to queries from 6to4 hosts, this might show a > >> drop again in the German graphs. > > > > Would that be "DENIC"? If yes, can you point me to the Nanog article? > > Yeah, sorry for the typo: > > http://mailman.nanog.org/pipermail/nanog/2010-February/018162.html Mmmh. To clarify: this is not "DENIC not responding to DNS queries (packets) from 6to4 addresses" but this is "DENIC refusing to delegate a new .de domain to nameservers that have (only) 6to4 connectivity". DENIC does DNS checks before delegating a zone.de, and their rules are numerous and amazing... But in *this* case, I'm not going to argue the case - the usefulness of 6to4 connectivity for a name server is something which you can spend debating hours and hours, and people will still disagree :-) > > (Since we're providing IPv6 transit to DENIC, it might be a problem with > > our 6to4 relay - or with their routing. They're multihomed, they make > > their own mistakes^Wdecisions...) > > Love to hear if in fact this is policy or simply a technical issue and > bad translation from a service representative. It's policy, and it's not a technical issue. So as a transport provider, there is nothing we can do about it. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 144438 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From Sam.Wilson at ed.ac.uk Fri Feb 12 15:58:25 2010 From: Sam.Wilson at ed.ac.uk (Sam.Wilson at ed.ac.uk) Date: 12 Feb 2010 14:58:25 GMT Subject: [ipv6-wg] /127 for point to point links In-Reply-To: Your message <292AF25E62B8894C921B893B53A19D973972CBD89F@BUSINESSEX.business.ad> Message-ID: <201002121458.o1CEwPqr000891@holyrood.ed.ac.uk> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From michael.dillon at bt.com Fri Feb 12 17:14:57 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 12 Feb 2010 16:14:57 -0000 Subject: [ipv6-wg] /127 for point to point links In-Reply-To: <4B753A3E.3010209@sweet-sorrow.com> Message-ID: <28E139F46D45AF49A31950F88C4974580527155F@E03MVZ2-UKDY.domain1.systemhost.net> > Well, personaly as being the first commecial ipv6 provider in > our country I had the same reservations. But after a talk > with our IPv6 experts (go6.si) I/we just accepted the fact > that we're wasting perfectly good address space and we just > put /64 on P2P links... What would you prefer to waste? Money or address space? If you use a /64 for every point-to-point circuit then you are wasting address space, instead of wasting money paying for someone to put twice as many bits of silicon into the circuitry that handles routing and forwarding. Anybody who thinks that doing the "right thing", as advised by the IETF, is wasteful, needs to get their priorities straight. We have enough problems getting transitioned to IPv6 and we don't need providers who think that they are smarter than the rest of us and will just reinvent the wheel and force /127 prefixes on their peering partners. Remember this statement? RFC 3627 states that /127 is considered harmful, however I do feel this RFC confuse people since it doesn't propose a definite solution. It suggests a number of solutions and indicates using /64 is the right thing. Using /64 is the right thing. That means that on peering links with another provider, best practice is to follow the RFCs and use /64. If you want to experiment with other prefixes in your network, then go ahead, but on interfaces with others, follow best practices. By the way, that also means giving no less than a /56 to a private residence and no less than a /48 to any site. It's not your job to tell other people how to run their network. --Michael Dillon From michael.dillon at bt.com Fri Feb 12 17:21:39 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 12 Feb 2010 16:21:39 -0000 Subject: [ipv6-wg] /127 for point to point links In-Reply-To: Message-ID: <28E139F46D45AF49A31950F88C49745805271577@E03MVZ2-UKDY.domain1.systemhost.net> > RFC 3627 is informational RFC. Does not describe any strict > rules. Read the RFC and understand /127 is harmful only in > certain cases: > poin-to-point link + usage of subnet anycast. Other problems > might exist as described in section 5. Chaos is harmful. Following consistent best practice on peering links is a good idea. > http://www.ietf.org/id/draft-kohno-ipv6-prefixlen-p2p-00.txt Yes, perhaps saying that /64 on all peering links is a bit too simplistic. Nevertheless, I do believe that everyone should follow best practice on peering links. This WG seems like a good place to agree on the specifics of what that best practice is since RFC 3627 is a bit too general for this. What do others think of drafting an IPv6 best practices document in this WG that is specifically for network operators? --Michael Dillon From david.kessens at nsn.com Fri Feb 12 20:20:01 2010 From: david.kessens at nsn.com (David Kessens) Date: Fri, 12 Feb 2010 11:20:01 -0800 Subject: [ipv6-wg] Discussion period for co-chair selection until 20100208 In-Reply-To: <201002121104.44523.kzorba@otenet.gr> References: <20100203224405.GR4736@nsn.com> <201002081445.51070.kzorba@otenet.gr> <20100210003649.GD18940@nsn.com> <201002121104.44523.kzorba@otenet.gr> Message-ID: <20100212192000.GN5130@nsn.com> Kostas, On Fri, Feb 12, 2010 at 11:04:44AM +0200, Kostas Zorbadelos wrote: > > Is this document part of a work in progress that will eventually be published > somewhere? We don't have a written down process for such a type of document but essentially it gets updated when somebody picks up the authorship again and does an update. I cannot speak for the other working group chair people but I will personally support that it will be officially published if it is a bit more ready. > Documents like these can help newcomers understand how RIPE WG communities > operate and also add to the openness of these forums. I fully agree. David Kessens --- From kzorba at otenet.gr Sat Feb 13 13:03:54 2010 From: kzorba at otenet.gr (Kostas Zorbadelos) Date: Sat, 13 Feb 2010 14:03:54 +0200 Subject: [ipv6-wg] /127 for point to point links In-Reply-To: <28E139F46D45AF49A31950F88C49745805271577@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C49745805271577@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <201002131403.54443.kzorba@otenet.gr> On Friday 12 February 2010 06:21:39 pm michael.dillon at bt.com wrote: > > What do others think of drafting an IPv6 best practices > document in this WG that is specifically for network operators? > BCP documents (as in Best Current or Common Practices) I believe should be a target outcome of any RIPE WG. The more focused on people actually running IP networks and services the better for me. In short, I agree. Regards, Kostas Zorbadelos From marcoh at marcoh.net Sat Feb 13 13:14:15 2010 From: marcoh at marcoh.net (Marco Hogewoning) Date: Sat, 13 Feb 2010 13:14:15 +0100 Subject: [ipv6-wg] /127 for point to point links In-Reply-To: <28E139F46D45AF49A31950F88C49745805271577@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C49745805271577@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <08F67F8D-5AD4-43A4-89D8-577681174A10@marcoh.net> > What do others think of drafting an IPv6 best practices > document in this WG that is specifically for network operators? Looking forward to a first draft of this. Is it worth joining up with the routing WG who is, I believe, busy with something on filtering recommendations and deaggregation ? MarcoH From joao at bondis.org Mon Feb 15 09:19:47 2010 From: joao at bondis.org (=?iso-8859-1?Q?Jo=E3o_Damas?=) Date: Mon, 15 Feb 2010 09:19:47 +0100 Subject: [ipv6-wg] /127 for point to point links In-Reply-To: <08F67F8D-5AD4-43A4-89D8-577681174A10@marcoh.net> References: <28E139F46D45AF49A31950F88C49745805271577@E03MVZ2-UKDY.domain1.systemhost.net> <08F67F8D-5AD4-43A4-89D8-577681174A10@marcoh.net> Message-ID: On 13 Feb 2010, at 13:14, Marco Hogewoning wrote: >> What do others think of drafting an IPv6 best practices >> document in this WG that is specifically for network operators? > > > Looking forward to a first draft of this. Is it worth joining up with the routing WG who is, I believe, busy with something on filtering recommendations and deaggregation ? > True, ever since AP-wg agreed that routing considerations, such as (de)aggregation, would be better reflected in a routing document than in an address policy one. Work has been headed by Rob Evans and Sander steffann with help. see http://www.ripe.net/ripe/wg/routing/r59-minutes.html, the minutes for RIPE 59. Look at the last item in the minutes Joao From michael.dillon at bt.com Mon Feb 15 10:17:42 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 15 Feb 2010 09:17:42 -0000 Subject: [ipv6-wg] /127 for point to point links In-Reply-To: <08F67F8D-5AD4-43A4-89D8-577681174A10@marcoh.net> Message-ID: <28E139F46D45AF49A31950F88C49745805271852@E03MVZ2-UKDY.domain1.systemhost.net> > > What do others think of drafting an IPv6 best practices document in > > this WG that is specifically for network operators? > Looking forward to a first draft of this. Is it worth joining > up with the routing WG who is, I believe, busy with something > on filtering recommendations and deaggregation ? Why not start with some of the material on ARIN's IPv6 wiki? For instance the following page could serve as the start of a best practices document on IPv6 addressing plans. --Michael Dillon From mohacsi at niif.hu Mon Feb 15 10:21:00 2010 From: mohacsi at niif.hu (Mohacsi Janos) Date: Mon, 15 Feb 2010 10:21:00 +0100 (CET) Subject: [ipv6-wg] /127 for point to point links In-Reply-To: <28E139F46D45AF49A31950F88C49745805271852@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C49745805271852@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: On Mon, 15 Feb 2010, michael.dillon at bt.com wrote: >>> What do others think of drafting an IPv6 best practices document in >>> this WG that is specifically for network operators? > >> Looking forward to a first draft of this. Is it worth joining >> up with the routing WG who is, I believe, busy with something >> on filtering recommendations and deaggregation ? > > Why not start with some of the material on ARIN's IPv6 wiki? For > instance the following page > could serve as > the start of a best practices document on IPv6 addressing plans. Also you can look at 2 tutorials: http://www.6deploy.org/tutorials/031-IPv6_addr_case_RENATER_Hungarnet_v0_1.pdf http://www.6deploy.org/tutorials/131_Campus_IPv6_deployment_consideration_v0_6.pdf Janos Mohacsi Head of HBONE+ project Network Engineer, Deputy Director of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 > > --Michael Dillon > > From marc.blanchet at viagenie.ca Mon Feb 15 12:58:07 2010 From: marc.blanchet at viagenie.ca (Marc Blanchet) Date: Mon, 15 Feb 2010 06:58:07 -0500 Subject: [ipv6-wg] /127 for point to point links In-Reply-To: References: <28E139F46D45AF49A31950F88C49745805271577@E03MVZ2-UKDY.domain1.systemhost.net> <08F67F8D-5AD4-43A4-89D8-577681174A10@marcoh.net> Message-ID: <4B7936CF.2020105@viagenie.ca> Jo?o Damas a ?crit : > On 13 Feb 2010, at 13:14, Marco Hogewoning wrote: > >>> What do others think of drafting an IPv6 best practices >>> document in this WG that is specifically for network operators? >> some: - address plan: RFC3531 - special IPv6 prefixes (the ones who usually need to be filtered): RFC5156 Marc. >> Looking forward to a first draft of this. Is it worth joining up with the routing WG who is, I believe, busy with something on filtering recommendations and deaggregation ? >> > > True, ever since AP-wg agreed that routing considerations, such as (de)aggregation, would be better reflected in a routing document than in an address policy one. Work has been headed by Rob Evans and Sander steffann with help. see http://www.ripe.net/ripe/wg/routing/r59-minutes.html, the minutes for RIPE 59. Look at the last item in the minutes > > Joao -- ========= IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN news service: http://reeves.viagenie.ca NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca From olivia at ripe.net Tue Feb 16 13:32:03 2010 From: olivia at ripe.net (Olivia Mijnals-Ruimwijk) Date: Tue, 16 Feb 2010 13:32:03 +0100 Subject: [ipv6-wg] Announcement: RIPE NCC Training Courses Message-ID: <4B7A9043.3010506@ripe.net> [Apologies for duplicate e-mails] Dear Colleagues, The RIPE NCC invites you to register for one of our upcoming training courses: - The LIR Training Course This course teaches LIRs how to request Internet number resources and interact with the RIPE NCC. A course outline is available at: http://www.ripe.net/training/lir/outline.html - The Routing Registry Training Course This course teaches LIRs how to use the RIPE Database for routing. A course outline is available at: http://www.ripe.net/training/rr/outline.html - The IPv6 Training Course This course teaches LIRs about the need for IPv6 and includes basic information on how to plan your deployment. A course outline is available at: http://www.ripe.net/training/ipv6/outline.html To see the location of upcoming courses and to register, please use the LIR Portal or complete the registration form on our website at: RIPE NCC Upcoming Courses List & Registration https://lirportal.ripe.net/lirportal/training/course-list.html If you have any questions, please do not hesitate to contact us at . Kind regards, Rumy Kanis Training Services Manager RIPE NCC From denis at ripe.net Wed Feb 17 18:00:39 2010 From: denis at ripe.net (Denis Walker) Date: Wed, 17 Feb 2010 18:00:39 +0100 Subject: [ipv6-wg] Publication of default assignment sizes for end-user network ? Message-ID: <4B7C20B7.9040009@ripe.net> >>> Now this does not forbid you to register individual >>> assignments into the public database, but doing so poses >>> various problems. Not only the sheer number of assignments >>> can be a problem, but also keeping that registration >>> up-to-date will have serious impact on your day to day >>> operations and especially with residential users there might >>> be privacy issues as well. >> >> If we would have a distributed database protocol to extend the >> RIPE database into the LIRs, then this would not be an issue. >> I'm thinking of something like DNS. >> >> For instance, if I need to look up data on three >> /48s in fdb8:e914::/32 I would first send a lookup request to >> RIPE. The RIPE db would tell me that all data for >> fdb8:e914::/32 is in a server at fdb8:e914::dbdb. I would >> cache that information, and send my first lookup request to >> the distributed server. After getting my reply, I would prepare >> to send the second request for fdb8:e914:c20f::/48, notice that >> the /32 is already in my cache, and use the cached server >> instead. >> >> This is roughly the way DNS lookups work with the result that >> the detailed data does not have to be kept in one central >> location. I would like to see the RIPE db move in the same >> direction. >> >> At the same time, I would like to see the spec opened up a bit >> so that the distributed server operators would be free to add >> additional attributes to existing objects, and additional objects >> so that there is the possibility of using the same distributed >> lookup mechanism for geographic or language identifications as >> well. > > This may as well be another solution, but it still needs some way of > signalling where the actual boundary between customers is as I see > no way to delegate it down to the customer level unless there is > some way to incoorperate it into the CPE. > > And that's I think my main argument opposing to this path, it takes a > lot of time to and develop that model ad get it implemented across > all the LIR's. The big benefit of solving it at the RIR level is that it's > only a handfull of systems that need to be changed and the basic way > to retrieve that information is already there in the form of the whois > protocol. > > I'm not syaing I don't like your solution, I'm just afraid that > deployment will be just to late. > > Grtx, > > Marco Hi Marco Sorry for the late response. I missed the original posting on this list, then saw your follow up on the IETF list. The RIPE NCC also has the same problem with the RIPE DB. Currently we implement some rate limiting on individual IP addresses. As you have explained here, this does not scale for IPv6. The Database Group at the RIPE NCC has already done a lot of thinking internally on this and other issues on moving the RIPE Database into an IPv6 world. We would welcome ideas and thoughts from the community about use cases, issues and problems you can foresee with the RIPE DB in an IPv6 world, even if people don't have the solutions. Of course suggested solutions are also welcome. Let me throw some pointers at you from our thinking. Firstly don't let your thoughts be constrained by the current RIPE DB. This was designed in an IPv4 world with IPv6 bolted on later. Think out of the box. Don't worry too much about the data model, interfaces, APIs, tools we have now. Focus on what the RIPE DB needs to do for you in an IPv6 world. For example you discuss the problem of not knowing what the block size is that any IPv6 address belongs to. This is because the current thinking is to not store all assignments in the RIPE DB. Suppose we re-assess what data needs to be stored, who needs access to it and for what purpose. Suppose we design a new data model and provide new APIs and new tools built on those APIs. Then one possibility may be for each LIR to upload a daily dump of assignment changes and leave it up to the RIPE NCC to process the data. We can do batch processing over night and sync the RIPE DB with LIR's databases. This will not have the serious impact you referred to on your day to day operations. We don't need to store the same information we do now for an IP address. We can store different information about addresses used for different purposes. Maybe not all the stored information needs to be accessible by all people who query the RIPE DB. So we can build in data protection safeguards. With new query interfaces, we can provide access to this data more easily and in many different formats. So perhaps you can widen your thinking now about possible solutions to new problems in an IPv6 world. Regards Denis Walker Business Analyst RIPE NCC Database Group From david.kessens at nsn.com Mon Feb 22 19:04:15 2010 From: david.kessens at nsn.com (David Kessens) Date: Mon, 22 Feb 2010 10:04:15 -0800 Subject: [ipv6-wg] Confirmation of Marco Hogewoning and Shane Kerr as co-chairs Message-ID: <20100222180414.GA21277@nsn.com> All, Our last call to confirm: Shane Kerr http://www.ripe.net/ripe/maillists/archives/ipv6-wg/2010/msg00038.html and Marco Hogewoning http://www.ripe.net/ripe/maillists/archives/ipv6-wg/2010/msg00041.html as additional co-chairs for the ipv6 working group has ended. I have not received a single objection. I did receive a large number of positive responses before and after the Last Call started. If you like, all responses were posted to the mailing list and can be viewed by checking the working group mailing list archives. I believe we have now reached consensus to appoint Marco Hogewoning and Shane Kerr as co-chairs for the ipv6 working group. I would like to thank everybody for your participation in the discussion and I would like to welcome Shane and Marco as my co-chairs. Thanks! David Kessens --- From jan at go6.si Mon Feb 22 19:08:07 2010 From: jan at go6.si (Jan Zorz @ go6.si) Date: Mon, 22 Feb 2010 19:08:07 +0100 Subject: [ipv6-wg] Confirmation of Marco Hogewoning and Shane Kerr as co-chairs In-Reply-To: <20100222180414.GA21277@nsn.com> References: <20100222180414.GA21277@nsn.com> Message-ID: <4B82C807.8080609@go6.si> David Kessens wrote: > I would like to thank everybody for your participation in the > discussion and I would like to welcome Shane and Marco as my > co-chairs. > Congratulations to Marco and Shane, good job done David :) Jan Zorz From Fernando.Garcia at tecnocom.es Mon Feb 22 20:30:57 2010 From: Fernando.Garcia at tecnocom.es (=?iso-8859-1?Q?Garc=EDa_Fern=E1ndez=2C_Fernando?=) Date: Mon, 22 Feb 2010 20:30:57 +0100 Subject: [ipv6-wg] Confirmation of Marco Hogewoning and Shane Kerr as co-chairs In-Reply-To: <4B82C807.8080609@go6.si> References: <20100222180414.GA21277@nsn.com> <4B82C807.8080609@go6.si> Message-ID: <131C193B-27F8-43F6-9CEA-785CA4729409@tecnocom.es> +1 Congrats to the three of them and to the working group. I think this will help foster the group now that IPv6 looks really soon now. Regards, Fernando El 22/02/2010, a las 19:08, Jan Zorz @ go6.si escribi?: > David Kessens wrote: >> I would like to thank everybody for your participation in the >> discussion and I would like to welcome Shane and Marco as my >> co-chairs. >> > Congratulations to Marco and Shane, good job done David :) > > Jan Zorz > -- Tecnocom Fernando Garc?a Fern?ndez D.G. Integraci?n de Redes y Sistemas Josefa Valcarcel, 26 Edificio Merrimack III Madrid - 28027 Tel. Fijo: 901900900 ext 40383 Fax: (+34) 914313240 Tel. M?vil: (+34) 649428591 E-mail: fernando.garcia at tecnocom.es http://www.tecnocom.es From internetplumber at gmail.com Thu Feb 25 15:53:54 2010 From: internetplumber at gmail.com (Rob Evans) Date: Thu, 25 Feb 2010 14:53:54 +0000 Subject: [ipv6-wg] /127 for point to point links In-Reply-To: References: <28E139F46D45AF49A31950F88C49745805271577@E03MVZ2-UKDY.domain1.systemhost.net> <08F67F8D-5AD4-43A4-89D8-577681174A10@marcoh.net> Message-ID: <9a8fa98b1002250653w3a44ac17v69fa0dd073e1a788@mail.gmail.com> > True, ever since AP-wg agreed that routing considerations, such as (de)aggregation, would be better reflected in a routing document than in an address policy one. Work has been headed by Rob Evans and Sander steffann with help. see http://www.ripe.net/ripe/wg/routing/r59-minutes.html, the minutes for RIPE 59. Look at the last item in the minutes Sorry for the slow reply. ?An update to the IPv6 route filtering recommendations document has been on my todo list since Lisbon (and I've been chased about it a few times by some people), but I've had little chance to devote much time to it. I do aim to get it done well before Prague. However, I've been quite fond of keeping the document short and focused, so whilst I'd be happy for an IPv6 BCP to reference it, I'd need to be persuaded to add much more to it. Cheers, Rob