- ipv6-wg - mailman.ripe.net

Interest in IPv6-only world?
by Shane Kerr 09 Aug '13

09 Aug '13

All, I saw this today: http://wiki.test-ipv6.com/wiki/Main_Page And I was thinking about the seeming increase in interest recently in researching the realities of an IPv6-only world. According to Cisco's IPv6 stats site: http://6lab.cisco.com/stats/ We're a long way from having most content available over IPv6... but not *that* long, if we can take the 40% numbers seriously. So I guess this is mostly a "setting the groundwork" for now, but maybe not. Does anyone actually run an IPv6-only network now, or is thinking about it? (As in, without a gateway to the IPv4 world.) Cheers, -- Shane

4 3

Fwd: IPv6 Hackers meeting (Berlin 2013): Slideware and videos
by Fernando Gont 08 Aug '13

08 Aug '13

Folks, FYI -------- Original Message -------- Date: Thu, 08 Aug 2013 11:11:06 -0300 From: Fernando Gont <fgont(a)si6networks.com> To: IPv6 Hackers Mailing List <ipv6hackers(a)lists.si6networks.com> Subject: IPv6 Hackers meeting (Berlin 2013): Slideware and videos X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Folks, I've uploaded the slideware of most of the presentations, and have also included links to the videos uploaded by Dan. Everything is available here: <http://www.ipv6hackers.org>. Enjoy! -- Fernando Gont SI6 Networks e-mail: fgont(a)si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

1 0

IPv6 WG RIPE 66 (draft) minutes
by MarcoH 22 Jul '13

22 Jul '13

Dear colleagues, Attached are the draft minutes of our sessions in Dublin. Many thanks to Mirjam for writing them all up. Please review them and if you have any comments or corrections please reply to this list before Friday July 12th. If by that date we haven't received any major corrections we will assume that there is consensus to declare these as final and publish them on the website. Thanks, Marco on behalf of the WG chairs. > ---- > > RIPE 66 > Scribe: Mirjam Kuehne > WG chairs: David Kessens, Shane Kerr, Marco Hogewoning > Date: 15 May 2013, 14:00 - 15:30 > IPv6 WG Meeting (first session) > > A. Welcome and Administrative Business > > Marco opened the first IPv6 WG session. This session focused on implementing IPv6. The minutes of the RIPE 65 IPv6 WG meeting were circulated and are now approved. > > B. Implementing Full IPv6 Support: More than Binding to an AF_INET6 Socket - Bert Hubert, PowerDNS/Netherlabs > > The presentation is available for download at: https://ripe66.ripe.net/presentations/134-Making_an_application_fully_IPv6_… > > Andrew Yourtchenko, Cisco, pointed to RFC 6555 (Happy Eyeballs: Success with Dual-Stack Hosts) and suggested that people take a look at this document. He added that the "Update Specification of the IPv4 ID Field" is now also a standard (RFC 6864). He wondered if it would make sense to set up some sort of a library where people could store pieces of code. > > Bert responded that instead of setting up a library, people could publish their code snippets and say "If you take this bit of code, it will help your IPv4-to-IPv6 migration." He said he would like to prevent people from having to double their source code, which is already too long. > > Andrew added that there would be some code snippets in his presentation later in this WG session. > > Benedikt Stockebrand, Stepladder IT Training+Consulting GmbH, commented that there are three viable options: v4-only, v6-only or both. There is a fourth option which is to leave it to whatever the default setting is in a particular operating system, but that can be problematic. One really needs to think about this beforehand and the biggest problem is explaining to people how to do this properly. Benedikt also commented that one should normally not touch link-local addresses, because as soon as one uses link-local addresses, the application forces one to put multiple machines on the same network, which should be avoided. Furthermore, multiple addresses in the DNS are essentially a necessity. That is independent of IPv6, but in IPv6 it is even more important. The last thing Benedikt mentioned was related to ACLs. He said that sometimes you can work around it with a small hack, using a local packet filter instead of an application-related ACL. > > Bert responded that he agrees with the comment on link-local addresses, but in the “real world” there are people who say this is what we need to do. > > Dan York, ISOC, thanked Bert for the presentation. He also wanted to second Andrew who pointed to RFC 6555. Furthermore, there are other related draft documents coming out of the IETF right now (“Happy Eyeballs for Foo”) that look at mechanisms of testing both and figuring out which one is fastest. Finally, there is a RFC 5952 that says that you should use the brackets with the colon, so choice A is now made by most people. > Bert added that Dan York actually wrote a book on this topic that contains everything he presented and much more. > > Ondrej Filip, CZ.NIC, commented on the IPv6-only behaviour and said that the RFC specifies that you get both IPv4 and IPv6. However, if you configure your operating system to something different, it might break, because some applications assume the default behaviour. > > Bert agreed that it is a policy that can be set, but it seems to be confusing for people. > > C. Non-Working Clients” – Andrew Yourtchenko (private contribution) > > The presentation is available at: > https://ripe66.ripe.net/presentations/114-RIPE-IPv6-only-Clients-RIPE.pdf > > Jen Linkova, Google, said she liked the presentation and that it is good to let people know that IPv6-only doesn't work properly on Android. > > Andrew added that one thing he forgot to mention is that on the non-WiFi, it actually works. > > Marco Hogewoning, WG Co-Chair, asked the audience how many people wanted the RIPE NCC to provide an IPv6-only WiFi network during the RIPE Meetings. Many hands went up. He then asked how many people fear that the connectivity would not be good enough: fewer hands went up. Marco said he would pass this on to the RIPE Meeting Technical Team and see what can be done next time. > > ACTION RIPE NCC: To look into the possibility to provide a IPv6-only WiFi network at RIPE 67. > > > D. The Latest Developments in DHCPv6 - Tomek Mrugalski, Internet Software Consortium > > The presentation is available at: > https://ripe66.ripe.net/presentations/158-latest-development-in-dhcpv6.pdf > > Shane Kerr, WG Co-Chair, asked Tomek what he thinks the typical time is between a new technology getting standardised in ‘DHCP land’ and it being deployed to production. > > Tomek responded that this really depends on the nature of the technology and also on how the project is managed and how many people are involved. For instance, the DS-Lite standard was deployed very quickly whereas other implementations took over a year. > > Paul Ebersman, Infoblox, asked if the new relay option of getting the hardware address included in the ISC roadmap for getting into the server to be able to consume that information for getting it into the release? > Tomek explained that this is up to the server's allocation policy. For instance, you can log it so that you have an answer if law enforcement want to know from which address some bad activity was originated (this is a legal requirement in some countries). Another use case is that you can assign addresses and prefixes based on the server configuration. And finally, you can perform access control where you can, for example, maintain a blacklist for specific addresses or a whitelist for known clients. > > Paul agreed that there are many use cases and said that some of his customers are quite interested. He would be interested in two requirements, one being that we must have relay code that actually inserts that information (for that requirement, we need to push the vendors). But we also need the DHCP server to actually get the information in the packet and then into the lease, for instance. Are there any plans for ISC to do this? > Tomek said he couldn’t confirm or deny this. > > Benedikt Stockebrand was wondering why Tomek is so worried about scalability, because he thought the obvious approach would be to set up several DHCP servers and spread the subnets across them. But he would prefer the simple solution to set up a suitably sized single DHCP server that can handle the full set of subnets. > > Tomek clarified that he wasn't saying that one needed to deploy the load balancer or fail-over in every single network. Provided the server is powerful enough to support all the traffic then that's also fine. > Benedikt elaborated that the problem he sees is that of additional complexity. > > Tomek said he agreed with this concern. The second draft that he presented actually discusses cases where the failover is not necessary. He said he would consider failover as the last resort. > > Benedikt added that he believes that DHCP is one of those areas in which one doesn't need the multiple servers to share the load, and that one could solve the scalability issues without adding any complexity in the protocol. But if it is described like that in the specs, people think they will have to implement it that way. > > Tomek said that, like with other DHCP extensions, this is not a mandatory feature. It is mostly an implementation issue and he hopes that every implementer will actually disable this by default. > > Marco suggested that this be discussed further on the IETF mailing list (DHCP-WG). > > E. Dave Täht: “Fixing Bufferbloat with cerowrt” https://ripe66.ripe.net/presentations/237-cerowrt_vs_an_uncaring_universe.p… > > Vesna Manojlovic, RIPE NCC, said he really likes this project and would like to help him expose it to many more women and children (this was related to a comment Dave Täht made in his presentation where he said that this is still a research project and "please do not expose this to your women and children."). > > Ragnar Anfinsen congratulated Dave on his good work. He added that he is currently busy specifying CPEs for his company and is wondering if he should include the one Dave was presenting. > > Dave responded that he would like people to look deeply into OpenWRT, which is only about 8 Linux kernels and 8 demons, and to let him know what else should be included. > > Vaibhav Baijpai, Jacobs University Bremen, wondered if there were any plans to accept tools that perform active measurements tests? > > Dave confirmed that this was the case. He was now at the point where he trusted the underlying stack and would be happy to add more tools. > > The same speaker also asked if there are any plans to collaborate with the RIPE NCC's RIPE Atlas Team because RIPE Atlas was not WRT-compatible. > > Dave said that adopting a different hardware platform right now would take a lot of time, but that he was happy to help. > ----------- > > RIPE 66 > Scribe: Mirjam Kuehne > WG chairs: David Kessens, Shane Kerr, Marco Hogewoning > Date: 15 May 2013, 09:00 - 10:30 > IPv6 WG meeting (second session) > > Marco Hogewoning opened the second session of the IPv6 WG. This session was focused on measuring IPv6. > > A. Vaibhav Bajpai (RACI Talk): “Measuring Effectiveness of Happy Eyeballs” > > The presentation is available at: > > https://ripe66.ripe.net/presentations/263-ripe66-happy-slides.pdf > > Jen Linkova, Google, commented on the statement that the happy eyeball winner is usually slower. This is still an action item for most ISPs, because currently the IPv6 experience is not in sync. Nobody wants to do it, but it has to be done. > > Vaibhav added that he was doing these measurements for three months (February - April). In the first month he observed that Google services had higher means and standard deviations, but in the last month this has gone. It looked like something has been done at Google internally. > > Jen said that some of the different behaviour in IPv4 vs. IPv6 could also be due to quality of service. > > Carsten Strotmann, Men & Mice, asked what operating system was used for the measurements and if he had tested it using Windows. > > Vaibhav responded that he used Sam Knows probes and OSX. The Teredo box was running Linux. Windows was not tested. > > Carsten offered to work together on this with Vaibhav. > > Martin Levy, Hurricane Electric, commented that it is quite common to have different routing for IPv4 and IPv6 (different peering partners and different propagation of routes) and suggested to find a particular measurement point from where you can at least guarantee the beginning of the route propagation. Then go back and look at the measurements to determine if you see differences caused by a tunnel or something else in IPv6. > > Vaibhav responded that, in addition to doing ‘Happy Eyeball’ tests, they also did traceroutes over both IPv4 and IPv6. They then get the AS path information to see how different the IPv4 and IPv6 routes are. This provides some confidence in the measurements. > > > Andrew Yourtchenko, Cisco, suggested that Vaibah speak to the RIPE Atlas developers. The RIPE Atlas probes would provide a lot of good data for this project > > Vaibhav said that his tool is based on a single file with 800 lines of code; if the RIPE Atlas software developers would like to review the code, he would be happy to send it to them. It would also be beneficial to look at the RIPE Atlas measurements in greater detail. > > ACTION RIPE NCC: get in touch with Vaibhav and collaborate (RIPE Atlas). > > > B. Vesna Manojlovic, RIPE NCC: “IPv6 RIPEness Fifth Star” > https://ripe66.ripe.net/presentations/271-ripeness-5th-star-v2.key > > An audience speaker, SIDN, asked if the RIPE NCC was also checking the content of the web page listed on the Alex 1M list because, even if it accessible over IPv6, it could just be a parking page. He was also interested to find out if MX records were checked. > > Vesna said it was an interesting idea and although this wasn’t being done at the moment, it could probably be implemented. The HTTP fetch measurements in RIPE Atlas were already enabled. She added that she didn't think MX records were checked at the moment, but it was a good idea. > > Vaibhav suggested to check if the content is the same in IPv4 and in IPv6, and offered to use his tool for that. > > Vesna asked the audience if they thought they should remove the pages that are only parking pages. Many people nodded in approval of this suggestion. > > Niall O’Reilly, University College Dublin, suggested to look at the developments over time and possibly provide a graph at RIPE 67 that shows how many LIRs have gained and possibly lost their fifth star. > Marco asked what the audience thinks about raising the bar (from currently 2% to doubling it each year). People seemed to like the idea and some suggested to raise the bar at an even sharper rate. > > Daniel Karrenberg, RIPE NCC, clarified that most of the graphs Niall was asking for are already available on http://ipv6ripeness.ripe.net > > C. IPv6 Measurements Panel > Moderator: Marco Hogewoning, RIPE NCC > Panellists: > George Michaelson (APNIC), Andrew Yourtchenko (Cisco), Steve Nash (Arbor Networks), Heidi Kivekäs (FICORA),Martin Levy (Hurricane Electrics) > > Marco briefly introduced the panellists. Some panellists showed slides that illustrate their involvement in IPv6 deployment measurements: > > Steve Nash: https://ripe66.ripe.net/presentations/157-Arbor_IPv6.pdf > > Martin Levy: https://ripe66.ripe.net/presentations/309-RIPE_66_Dublin_-_IPv6_Measurement… > > George began by saying that Geoff Huston sent his apologies and that he really wanted to be at this panel, but was unfortunately unable to attend the RIPE Meeting this time. They were both really interested in the topic of “What is the correct question?” What should we ask about the transition to IPv6? How shall we measure it? There are traffic-related questions when we look at ISPs, IXPs, and others providing the underlying technology and infrastructure. There are also DNS-related questions that involve a different set of people in the industry. These people don't necessarily play with routers, but they are important for making things visible. And then there are questions about end devices and volume and scale, and questions about who consumes the information. The answers to all of these questions would provide an encompassing view. The aim is to get bits flying, and not only in transit, but to the end points. That led to the idea to measure how many people can actually get full IPv6 delivery in the system - to content and back again. And how do we get to all those millions of people? That's how the idea emerged to place these flash-based advertisements and use action scripts that fetch objects and invoke DNS functions. > > As a result, it was then possible for George and Geoff to perform a whole series of tests and to measure dual stack capability in the user’s browser preference. George thanked the people at Google who have been extremely generous and allowed them to use their advertising channel. He also thanked ISC, who provided a host in the US, and the RIPE community who, through the RIPE NCC, provided a server in Europe. Cisco had also provided some assistance. > George added that they noticed how people want to know how they are doing, similar to what the IPv6 RIPEness provides. It encourages the spirit of competition. Therefore, they have been compiling per-country and per-provider reports. Overall, the number of people who are already using IPv6 is really very large. In a global context, however, it's a low percentage. But in absolute terms that is a lot of people. If one starts to look at the breakdowns on a per-economy level, the dynamics are very different depending on the economy you are looking at. In Romania, for instance, there was one single, large AS that has achieved a certain level of saturation in the marketplace and since then there had been no more visible growth of IPv6 uptake. France is another example which is dominated by a single provider that has deployed 6RD. In Italy and Ireland the rate of uptake is very, very different. Graphing and understanding these individual scenarios can help with decision-making about IPv6. So, the main question behind this work was how can we inform the discussion - who can we engage with regarding the nature of IPv6 deployment? > > Steve Nash explained that Arbor Networks' primary business is creating software and systems for operators to deploy and to deliver denial of service protection services. This involves collecting a lot of data- data directly retrieved from systems deployed in the network, and through an annual survey that is has been running for eight years to date already (the ‘Worldwide Infrastructure Security Report’). Steve thanked all in the room who participate in this survey. In the recent survey, one quarter of the respondents confirmed that they had deployed IPv6 in their network, one half said they would be done by the end of the year, and for the rest it was longer than that. The survey also asks about the main concerns people have about IPv6. The main concern is traffic floods through DDOS attacks. However, when compared to IPv4, the numbers are the same, meaning that most people now view IPv6 as a normal service just like IPv4 and have the same concerns about both IPv4 and IPv6. This indicates a level of maturity of IPv6. > > Also, half of those that responded said that IPv6 will grow by 20% over the next year, and a quarter think growth will exceed 100%. In fact, IPv6 traffic more than doubled last year. Some measurements show that 0.2% of all traffic is over IPv6. That’s 45 terabits per second worldwide. Out of 265 operators worldwide, 80 are located in the RIPE NCC service region. However, from the operators in this region, one gigabit per second of native IPv6 traffic is produced. > > In conclusion, there seem to be many people out there that have IPv6 in their network who haven't completely rolled it out, so we don't measure any traffic. > > Andrew Yourtchenko presented a web site that aggregates a lot of data sources related to IPv6 deployment, such as number of prefixes allocated, number of prefixes announced, number of ASes that provide IPv6 transit, IPv6 accessible web pages (based on the Alexa 1Milllion list) and IPv6-enabled users (based on the APNIC Google Flash A data). Andrew mentioned that a big jump in allocated IPv6 prefixes was visible around May 2012 in Ireland, which could be attributed to preparations for World IPv6 Launch. On the other hand, a similar jump in announced IPv6 prefixes could not be observed. Another example Andrew presented was related to eyeballs - Germany, for instance, had very little eyeball penetration until autumn last year when steady growth began. > > Next, Martin Levy from Hurricane Electrics showed a graphical representation of networks interconnecting with other ASes. It shows that, while we can see complete IPv4 routing, there is a lack of routing inside the IPv6 world. Martin and others have been trying to encourage network operators to turn on IPv6, and he said it is amazing to see that we still dealing with this lack of global connectivity. He added that what he likes about the IPv6 RIPEness measurements is that it goes beyond just measuring the existence of a route. He concluded that there is still a lot of work to do until we get parity between IPv4 and IPv6. > > The last panel speaker was Heidi Kivecas from FICORA, the Finnish Communications Regulatory Authority. They are most interested in the users’ perspectives and conducted a survey amongst Finnish operators to see where things are with IPv6 deployment today (the last survey took place in 2008). However, Heidi said they mostly rely on other people's measurements. As a regulatory authority, FICORA is mostly interested in finding out why ISPs decide to deploy IPv6 and why others have decided not to, at least not for now. From her perspective, measurements are the most interesting aspect when helping ISPs solve their problems. > > Marco summarised that there are various ways to measure IPv6 deployments, from specific measurements on the network level, like RIPE Atlas does, to more soft measurements like the survey results shown by Steve Nash. He asked the panellists what their specific measurements were actually targeting. > > George responded that while he believes that dialogue with network providers, as enacted by Arbor and also by the measurement Martin mentioned, is absolutely necessary. At APNIC they felt that there is a level of strategic planning and decision-making that goes beyond technology. It is more about business investment and long-term national strategic decisions. For instance, if a vendor comes and says "We have this amazing CGN here, it’s a really cool device and if you buy it you don't have to do IPv6", there is a whole body of practice related to that path. He said that they are interested in the questions, "What kind of network do we want to have? Do we want to have an IPv6 network with end-to-end properties?” In order to answer these questions, one needs to find out where the gap is and how many people out there could do IPv6 if a capital investment decision would be made. Therefore, the work he is ultimately involved with is targeted to people like Heidi who are involved in industry and government planning decisions about what kind of network we want to have in the future. > > Martin responded that he is mostly interested in measuring at the BGP and access level. He said that instead of preaching to the converted, they need to go out and encourage network operators to finish the work they sometimes have already started but not completed. Eventually, he would like to see that people run pure IPv6, but there is still a lot of work to be done before that. > > Steve responded that they are gathering data for the operators on a day-to-day basis. He said that it is a little worrying that the statistics he showed are slightly lower than those shown by others. This indicates that the operators know less about what's going on at the end-points. > > Andrew added that they are mostly aggregating measurements, but also perform some of their own. He stressed that, in the end, it is not just about the protocol itself, but about the structure of the network. The measurements that all parties take collectively can help to make decisions and understand how operators can build their networks to ensure the continuation of the Internet. > > Heidi said that she is interested in both sides. As an engineer, her main responsibility is to maintain the technical quality inside Finnish networks. However, as a politician she is mostly interested in when the end users receive IPv6 access and services. > > George added that there are still some gaps in what is being done in terms of measurements and wondered if there are questions that aren't asked. He said that there is a poor understanding of the mobile sector and also of emerging Internet economies. They can have a big impact because they are the future markets. Regardless, the industry as a whole has done a good job in sharing the information it’s got. > > Marco wondered if the fact that we ran out of IPv4 should change the way measurements are done. Should we, for instance, look more at performance comparisons in IPv4 and IPv6? > > Steve said that there are things that need to be fixed, even the measurement aspect itself. He thinks people are not paying perhaps as much attention to gathering data as they should. > > Martin agreed and acknowledged that this is a problem. He observed a complete lack of instrumentation and differentiation between what's going on inside people's network in the IPv4 space, and the IPv6 space. He also commented on the business side that George mentioned. If an operator has no visibility in the money spent on CGN infrastructure vs. deploying IPv6, they cannot make the right decision. One has to look at the complete picture, including the internal network, in order to see what value IPv6 can bring. If operators only look at the low percentage of IPv6 traffic, it doesn't provide the full picture. And because of the happy eyeballs, users don't actually know and cannot complain. And that's what is both brilliant and annoying. > > Andrew agrees that often the monitoring tools are not in place, and that, at this point, the users must also be included in the troubleshooting tools. > Jen said that they should think about what data they needed. Sometimes they just look at the sets of data we are used to. She asked Steve about the concerns people who took the survey said they have such as “Is misconfiguration a higher concern in IPv6 than in IPv4?” > > Steve said no, it is at the same level - which is good. > > George added that this is good to know and that in fact a lot of the auto-config stuff is working pretty well so people don't have type in an IPv6 address manually. > > Andrew agreed and said that sometimes, as professionals, we are so used to the fact that the systems don't work and that we need to fix them by hand, that we don't trust enough that they actually do work. > George encouraged people to look at their own measurements. They might be surprised about how much IPv6 they have in their network. This might help to discover opportunities that they were not aware of. Measure to find out where you are, and use it to find out where you want to be. If we did a better job in understanding the mismatch between IPv4 and IPv6 routing, we would be in a better place. > > Martin said that he sat down with a vendor’s marketing team and, out of 12 chapters on the plan and equipment, only chapter 7 was about IPv6. He wondered why IPv6 wasn't included in each chapter. Therefore, no special chapter about IPv6 would be needed. Unfortunately the mindset still needs to be “Bring up an IPv4 network and then add IPv6 to it.” This needs to change. > > Marco wondered whom they needed to actively convince at this stage? The regulators? The operators? Should we use measures like IPv6 RIPEness and especially the fifth star to let people know that they are at the bottom of the rank and how to change that? > > In response, George said that he thinks it is better to compete by talking to each other than by chasing the bottom rank. He suggested people talk to their competitors about they do and don't do and why. They should also talk to their regulators and encourage them to provide incentives for IPv6 deployment. Also, measurement data can help with their planning. > Andrew suggested to use large measurements network like RIPE Atlas to measure to do some sort of background probing between the end points that have IPv6. We could check the round trip times between end points and see if it changes over time. We could then graph significant deviations in round trip times. > > Heidi, referred back to what George said, and stated that the main reason she is attending this meeting is to hear from ISPs as to what the main issues are. She can then report back to people who are not necessarily following forums like this. > > Steve concluded that he would keep watching as things change. > Martin stressed once more that a lot of work needs to be done and that the mindset of operators needs to change. IPv6 needs to be seen as an integral part of the network, not just like a test. > > Daniel Karrenberg said that some of the background measurements Andrew was suggesting were already being done in RIPE Atlas. For instance, measurements are done from every RIPE Atlas probe that does IPv6 back to the root name servers. The results can be found on the RIPE Atlas web site. The RIPE NCC also started to operate RIPE Atlas anchors at various places in the network that will also do IPv6 measurements. He encouraged people to get involved in RIPE Atlas and configure their own measurements. > > AOB: > > Wilhelm Boeddinghaus, Strato AG, suggested to keep the number of the RIPE document "Requirements for IPv6 in ICT Equipment (currently ripe-554) the same and add an errata section. This will be further discussed on the IPv6 WG mailing list. > > X. Close > > > > >

1 2

Global IPv6 Deployment Monitoring Survey Closing Soon
by Paul Rendek 18 Jul '13

18 Jul '13

Dear colleagues, This is a reminder to contribute to the fourth annual Global IPv6 Deployment Monitoring Survey, being conducted by the Number Resource Organisation (NRO). The survey aims to provide a better understanding of where the Internet community is going and what can be done to ensure the widespread adoption of IPv6. The results will be widely presented and discussed, with the support of the RIRs. The survey will take a maximum of 20 minutes to complete and can be found here: https://www.surveymonkey.com/s/GlobalIPv6survey2013 If you have any questions concerning the survey, please send an email to <info(a)gnksconsult.com> The survey closes on 31 July 2013. Kind regards, Paul Rendek Director of External Relations RIPE NCC

1 0

The Fourth Global IPv6 Deployment Survey is Now Open
by Serge Radovcic 01 Jul '13

01 Jul '13

[Apologies for duplicates] Dear colleagues, As in previous years, the Number Resource Organisation (NRO) invites you to participate in the 4th consecutive Global IPv6 Deployment Monitoring Survey on the current and future use of IPv6. The IPv6 Deployment Monitoring Survey is now online, and we encourage all members of our community to participate: https://www.surveymonkey.com/s/GlobalIPv6survey2013 The purpose of the survey is to better understand where the Internet community is going, and what can be done to ensure it is ready for the widespread adoption of IPv6. We hope this survey will establish a comprehensive view of current IPv6 penetration and future deployment plans for IPv6. This year’s survey is similar to those conducted in previous years (2010, 2011 and 2012), and will enable a comparison of progress. What is clear is that community participation does contribute to a better understanding of how IPv6 is being used. In 2012, 91% of the over 1,500 respondents indicated that they were interested in participating again in the 2013 survey. This survey has a maximum of 30 questions and will take about 20 minutes to complete. For those without IPv6 allocations or assignments, or have not yet deployed IPv6, the questions will be fewer in number. The survey will be open for a month and will close on 31 July 2013. Results of the IPv6 Deployment Monitoring Survey will be presented and discussed widely, with the support of your Regional Internet Registry (RIR). We appreciate your time and interest in completing this survey. If you have any questions concerning the survey, please send an email to <info(a)gnksconsult.com>. Kind regards, Serge Radovcic Chief Communications Officer RIPE NCC

1 0

Re: [ipv6-wg] [address-policy-wg] Cosmetic Surgery Project: Extended Review Period until 9 July on revised RIPE Policy document for IPv6 database objects
by Emilio Madaio 26 Jun '13

26 Jun '13

Dear Peter, thank you very much for your input and remark. I apologize if I forgot to include the IPv6 and Database WG mailing lists as decided during RIPE 66 on request of the community. I slavishly followed the procedure defined by the Cosmetic Surgery Project that was meant for the Address Policy WG mailing list only. The original announcement for the extended Review Phase is available at: http://www.ripe.net/ripe/mail/archives/address-policy-wg/2013-June/007931.h… For further feedback the draft of the policy document is online and ready for community review at: https://www.ripe.net/ripe/readability/improving-the-readability-of-ripe-doc… Please send your feedback on this draft document before 9 July 2013. Best Regards Emilio Madaio Policy Development Officer RIPE NCC On 6/25/13 5:51 PM, Peter Koch wrote: > On Tue, Jun 25, 2013 at 03:29:45PM +0200, Emilio Madaio wrote: > >> https://www.ripe.net/ripe/readability/improving-the-readability-of-ripe-doc… > > May I express some doubts about the 'cosmetic surgery project'? > The project was introduced as early as October 2009 and RIPE 513 was published > in February 2011. What appears to happen is a very late post publication copy > editing. In this particular case, the policy itself is a change to the > database attributes and - other than, say, address allocation/assignment > policies - not very likely read its own. Any structural changes > to the document (where's the template, by the way?) and changes to style > (passive voice here and there) or readability might better be invested > in the general database documentation. > > The new draft eliminates the data protection aspect from the > introduction/motivation section, which I consider a loss. The abstract > wins, though. The draft continues to use 2000::/46 for the example > where some chunk of 2001:DB8::/32 as per RFC 3849 might be a better choice. > > -Peter >

1 0

New on RIPE Labs: IPv6 Internet Pollution (by Manish Karir)
by Mirjam Kuehne 25 Jun '13

25 Jun '13

Dear colleagues, This new RIPE Labs article by Manish Karir and his colleagues presents the results of the IPv6 darknet experiment MERIT conducted end of last year: https://labs.ripe.net/Members/mkarir/ipv6-internet-pollution Kind regards, Mirjam Kuehne RIPE NCC

1 0

New on RIPE Labs: An Overview on IPv6 Security
by Mirjam Kuehne 18 Jun '13

18 Jun '13

Dear colleagues, Please see a new article on RIPE Labs, contributed by Johannes Weber who wrote his master's thesis on IPv6 Security: IPv6 Security - An Overview https://labs.ripe.net/Members/johannes_weber/ipv6-security-an-overview Kind regards, Mirjam Kuehne RIPE NCC

1 0

IPv6 addressing for broadband-connected remote sites
by stuart.dale＠ba.com 13 Jun '13

13 Jun '13

Is anyone aware of any thinking that has been done on how IPv6 addressing would work for enterprises with remote sites that are broadband connected? In the IPv4 we would deploy a router terminating a VPN tunnel back to our datacentres, with selected traffic being broken out locally to the internet, reliant on NAT'ing the client source addresses. In an IPv6 world how would this work? Since there's no capability of NAT'ing an IPv6 address to another IPv6 address, would it be better to address the clients within sites using PA addressing from the local ISP? This would lose the benefits of having sites allocated from a contiguous (summarisable) address space within the enterprise . On the other hand, if we addressed the sites from our PA address block, then unless I'm missing something, local ISP's would be unlikely to want to route to it as the addresssing wouldn't be in their block, would by definition almost certainly be a small subnet (probably single /64), and wouldn't fit into their standard provisioning model. Any comments / suggestions would be most welcome. ------------------------------------------------------------------------------------------------------------ Get the best from British Airways at ba.com http://www.ba.com -- This message is private and confidential and may also be legally privileged. If you have received this message in error, please email it back to the sender and immediately permanently delete it from your computer system. Please do not read, print, re-transmit, store or act in reliance on it or any attachments. British Airways may monitor email traffic data and also the content of emails, where permitted by law, for the purposes of security and staff training and in order to prevent or detect unauthorised use of the British Airways email system. Virus checking of emails (including attachments) is the responsibility of the recipient. British Airways Plc is a public limited company registered in England and Wales. Registered number: 1777777. Registered office: Waterside, PO Box 365, Harmondsworth, West Drayton, Middlesex, England, UB7 0GB. Additional terms and conditions are available on our website: www.ba.com

4 3

New on RIPE Labs: Evaluating the Effectiveness of Happy Eyeballs
by Mirjam Kuehne 13 Jun '13

13 Jun '13

Dear colleagues, We just published this new article by Vaibhav Baijpai on RIPE Labs: Evaluating the Effectiveness of Happy Eyeballs https://labs.ripe.net/Members/vaibhav_bajpai/evaluating-the-effectiveness-o… Vaibhav presented this at the recent RIPE 66 meeting during the IPv6-WG session. Kind regards, Mirjam Kuehne RIPE NCC

1 0

New on RIPE Labs: Measuring IPv6 Capability of RIPE Atlas Probes
by Mirjam Kuehne 12 Jun '13

12 Jun '13

Dear colleagues, Please see a new article on RIPE Labs contributed by Stephane Bortzmeyer: How Many RIPE Atlas Probes Believe They Have IPv6 (But Are Wrong)? https://labs.ripe.net/Members/stephane_bortzmeyer/how-many-atlas-probes-bel… Kind regards, Mirjam Kuehne RIPE NCC

5 4

Request to verify ipv6 addressing scheme in my diagram
by Maninder Singh 12 Jun '13

12 Jun '13

Hi Team, I have created a small IPv6 based corporate network diagram and want an expert to validate if the addressing scheme used is fine or not. I am attaching the diagram where I have created the network. Can you please assist me with validation of the address scheme and the network. If need be, I can speak to you on telephone or Skype too. But request you to help me by checking the diagram. Thanks Maninder Singh

3 3

Policy Proposal 2012-10 "Extension of IPv6 /32 to /29 on a per-allocation vs per-LIR basis" implemented
by Kjell Leknes 11 Jun '13

11 Jun '13

[Apologies for duplicate emails] Dear colleagues, We are pleased to announce that RIPE Policy Proposal 2012-10, "Extension of IPv6 /32 to /29 on a per-allocation vs per-LIR basis", has been implemented. The full policy proposal can be found at: http://www.ripe.net/ripe/policies/proposals/2012-10 [Open URL] The updated RIPE Document 589, "IPv6 Address Allocation and Assignment Policy", can be found at: http://www.ripe.net/ripe/docs/ripe-589 [Open URL] You can request this extension by submitting the IPv6 Additional Allocation Request Form through the LIR Portal, or by emailing it to hostmaster(a)ripe.net If you have any questions, please contact ncc(a)ripe.net Regards, Kjell Leknes Registration Services RIPE NCC

1 0

Call for Papers: RIPE 67
by Shane Kerr 07 Jun '13

07 Jun '13

All, This call for papers was sent to the RIPE list yesterday, and thought it might be of interest to participants in this working group. IPv6 is of interest to everyone, so a lot of IPv6-related topics are appropriate for the plenary... don't be afraid! :) Cheers, -- Shane Begin forwarded message: Date: Thu, 6 Jun 2013 10:42:39 +0200 From: Filiz Yilmaz <koalafil(a)gmail.com> To: "ripe-list(a)ripe.net" <ripe-list(a)ripe.net> Subject: Call for Papers: RIPE 67 Dear colleagues, Please find the CFP for RIPE 67 below. Note that the deadline for submissions is 4 August 2013 Kind regards Filiz Yilmaz for the RIPE Programme Committee http://www.ripe.net/ripe/meetings/ripe-meetings/pc --------------------------------------------------- Call for Papers: RIPE 67 A RIPE Meeting is an open event where Internet Service Providers, network operators and other interested parties get together. Although the meeting is mostly technical, it is also a chance for people to meet and network with others in their field. RIPE 67 will take place on 14-18 October 2013 in Athens, Greece. The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the Plenary, BoF and Tutorial sessions at RIPE 67. The PC is looking for presentations covering topics of network engineering and operations, including but not limited to: - IPv6 deployment - Managing IPv4 scarcity in operations - Commercial transactions of IPv4 addresses - Data center technologies - Network and DNS operations - Internet governance and regulatory practices - Network and routing security - Content delivery - Internet peering and mobile data exchange Submissions Attendees of the RIPE meetings are quite sensitive to keeping presentations non-commercial, and product marketing talks are strongly discouraged. Repeated audience feedback shows that the most successful talks focus on operational experience, research results, or case studies. For example, presenters wishing to describe a commercial solution should focus on the underlying technology and not attempt a product demonstration. Presenters who are proposing a panel or BoF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator. In addition to presentations selected in advance for the Plenary, the RIPE PC also offers several time slots for “Lightning Talks” which are selected immediately before or during the conference. The following requirements apply: - Proposals for Plenary talks, BoFs, Panels and Tutorials must be submitted for full consideration no later than 4 August 2013, using the meeting submission system at: https://ripe67.ripe.net/submit-topic/ Proposals submitted after this date will be considered on a space-available basis. - Presenters should indicate how much time they will require (30 minutes for Plenary talks is a common maximum duration, although some talks can be longer). - Proposals for talks will only be considered by the PC if they contain at least draft presentation slides (slides may be updated later on). For panels, proposals must contain a clear description as well as names of invited panelists, presenters and moderators. - Due to potential technical issues, it is expected that most if not all presenters/panelists will be physically present at the RIPE meeting. - Tutorials are sessions with educational content and are alotted about 2 hours. - BOFs (Birds of a Feather sessions) are informal gatherings on topics of shared interest among RIPE Meeting attendees. Technical facilities and logistical support are limited and provided based on best effort and availability. - Lightning talks should also be submitted using the meeting submission system. They must be short (10 minutes maximum) and often involve more timely topics. They can be submitted at any time. The allocation of lightning talk slots will be announced one day prior to the relevant session. If you have any questions or requests concerning content submissions, please email pc [at] ripe [dot] net. ------------------------------------------------------------

1 0

New on RIPE Labs: One Year Later - Who's Doing What With IPv6?
by Mirjam Kuehne 06 Jun '13

06 Jun '13

Dear colleagues, On the anniversary of the World IPv6 Launch, this new article takes a look at the readiness of networks to deploy IPv6, using statistics from the RIPE NCC service region and beyond: https://labs.ripe.net/Members/antony_gollan/one-year-later-whos-doing-what-… Kind regards, Mirjam Kuehne RIPE NCC

1 0

Re: [ipv6-wg] RIPE 554 Errata Page
by Merike Kaeo 28 May '13

28 May '13

OK, just got caught up on thread... On Tue 28/05/13 5:13 AM , Tim Chown <tjc(a)ecs.soton.ac.uk> wrote: > On 28 May 2013, at 13:00, "Jan Zorz @ go6.si" wrote: > > > On 5/28/13 1:12 PM, MarcoH wrote: > >> As was just discussing with Jan here in St Petersburg, I'm getting a > bit confused about where we are heading. > >> > >> Do we still want to compile a list of errors and find a way to "attach" > this to the 554 document as an errata? > >> > >> Or are we now gaining momentum to do a full revision and release a new > document superseding 554? Which of course should incorporate all the fixes > as well (and probably introduce some new mistakes) > >> > > This is a complex question now ;) > > > > I suggest that I make two lists - one with mistakes and errata material > in another one with significant changes suggestions. > > > > For a quick fix we could process "errata" small changes and when the > other list with bigger changes grows enough that we collectively decide we > need a new version of the document - we go and change it. > > > > Would that work? > > That sounds good. Works for me too. The one known issue for RIPE 554 is (and has been for a long time as Sander pointed out), the fact that we should have had RFC6105 instead of RFC 4862 since the intent was to make RA filtering mandatory. Jan has approached me a few times to see about helping edit a newer version and I am OK with that as long as there are enough changes to warrant a completely new document. We don't want to turn out a new RIPE doc every time one new v6 related RFC is published but certainly we should keep track of enhancements and modifications on best practices as deployments continue and then turn out a new document (and obsolete previous one(s)). - merike

2 1

Reminder:Cosmetic Surgery Project, new revised RIPE Policy, document for IPv6 database objects
by Emilio Madaio 28 May '13

28 May '13

Dear colleagues, As part of the Cosmetic Surgery Project, the RIPE NCC is moving forward with a review of the policy document ripe-513, "Value of the "status:" and "assignment-size:" attributes in INET6NUM objects for sub-assigned PA space". At the request of the proposers of the original policy proposal that produced ripe-513, we’re sending a reminder about the document review and inviting the IPv6 Working Group Mailing List and Database Working Group Mailing List subscribers to participate in the review process. A draft of the policy document is now online and ready for community review at: https://www.ripe.net/ripe/readability/improving-the-readability-of-ripe-doc… We encourage you to read the edited draft of ripe-513 and send any comments to <address-policy-wg at ripe.net> by 10 June 2013. Kind Regards, Emilio Madaio Policy Development Officer RIPE NCC

2 1

[training] RIPE NCC Training Courses July-September 2013
by Training Team 27 May '13

27 May '13

Dear Colleagues, Our training team travels the RIPE NCC service region to deliver training courses to our members without any additional cost. Over the next few months, we'll be in Rome, Chisinau, Munich, Moscow, Prague, London, Ljubljana, Yerevan, Malmö, Istanbul, Amsterdam. Visit the following page to register and to check which training courses we are giving in your area: https://lirportal.ripe.net/training/courses The RIPE NCC delivers the following training courses: - LIR Training Course - Database Training Course (new) - IPv6 for LIRs Training Course - Routing Security Training Course For more information visit: http://www.ripe.net/lir-services/training/courses With kind regards, Rumy Spratley-Kanis Training Services Manager

1 0

MERIT Darknet Experiment, Guidance Sought in Routing WG
by Daniel Karrenberg 15 May '13

15 May '13

Some of you may remember the short discussion here last November about the MERIT Darknet experiment and the subsequent change in our permission to MERIT. This RIPE meeting we have heard a presentation from MERIT/US-DHS about first results: https://ripe66.ripe.net/presentations/121-v6darknet-ripe2013.pdf Given this, the RIPE NCC is seeking guidance on what our permission to MERIT should be in the future. Here are a couple of slides which we will present in the routing-wg: https://ripe66.ripe.net/presentations/259-20130515-v6-darknet.key.pdf Any reactions are welcome. I suggest to have any discussion over on routing-wg(a)ripe.net. Daniel

1 0

New on RIPE Labs: Implementing Fifth Start IPv6 RIPEness
by Mirjam Kuehne 13 May '13

13 May '13

Dear colleagues, In this new article on RIPE Labs we present the first results of a fifth star for IPv6 RIPEness. This is a way to measure real IPv6 deployment in the RIPE NCC service region: https://labs.ripe.net/Members/emileaben/ipv6-ripeness-implementing-the-5th-… We would like to receive your feedback on a number of open question raised in the article. We also hope to see many of you at the IPv6 WG meeting in Dublin later this week where these results will be presented. Kind regards, Mirjam Kuehne RIPE NCC

1 0

RIPE 66 Draft Agenda version 2
by Marco Hogewoning 02 May '13

02 May '13

Dear Colleagues, Attached a copy of the latest draft agenda. As you may notice, this time round we opted for a couple of longer talks, which makes the speakers list a bit shorter than normal. Should there be any other topic you wish to discuss or you think we missed some important developments, please let us know. Your IPv6 WG Chairs, Marco, David and Shane Session 1 – Wednesday, 15 May 13:00 – 15:30 (Main Room) A) Welcome and Administrative Business B) “Implementing Full IPv6 Support: More than Binding to an AF_INET6 Socket” Bert Hubert, PowerDNS/Netherlabs C) "non-working clients" - TBC Andrew Yourtchenko, Cisco D) “The latest developments in DHCPv6″ Tomek Mrugalski, Internet Software Consortium Session 2 – Thursday, 16 May 09:00 – 10:30 (Side Room) A) "Measuring Effectiveness of Happy Eyeballs" - TBC B) "IPv6 RIPEness Fifth Star" Vesna Manojlovic, RIPE NCC C) IPv6 Measurements Panel Organisers: - Marco Hogewoning, RIPE NCC - Meredith Whittaker, Google/M-Lab Panellist: - Geoff Huston, APNIC - Mark Townsley, Cisco - Steve Nash, Arbor Networks (TBC) - Heidi Kivekäs, FICORA (TBC) X) Close

1 0

[training] New RIPE NCC IPv6 E-Learning tutorials
by Sandra Bras 02 May '13

02 May '13

[Apologies for duplicates] Dear colleagues, We are pleased to announce the launch of four new videos on IPv6 Transition Mechanisms as part of our online training. The topics include: - 6in4 - 6RD - NAT64 - DS-Lite You can watch them online at: https://www.ripe.net/lir-services/training/e-learning/ipv6/transition-mecha… Stay tuned! We plan to announce more exciting E-Learning news in the coming months. RIPE NCC E-Learning tutorials are provided as a free service available to everyone. If you have any questions, please feel free to contact us at: e-learning(a)ripe.net. Happy learning, Sandra Brás Trainer / E-Learning Project Manager

2 1

SI6 Networks' IPv6 Toolkit v1.3.4 released!
by Fernando Gont 18 Apr '13

18 Apr '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Folks, We have just released SI6 Networks' IPv6 Toolkit v1.3.4: a security assessment and troubleshooting toolkit for the IPv6 protocol suite. The toolkit is available at: <http://www.si6networks.com/tools/ipv6toolkit>, where you can find a the usual tarball, a GPG-signed version of it, a link to the toolkit's GIT repository, etc. This release features: * IPv6-host tracking support in the scan6 tool. * A new tool, address6, to analyze IPv6 addresses * Minor bug fixes The toolkit runs on (at least) the latest versions of Linux, FreeBSD, NetBSD, OpenBSD, and MacOS. Please send any bug reports and/or feature requests to <fgont(a)si6networks.com>. As always, you can get the latest news on IPv6 security research and tools by following us on Twitter: @SI6Networks. And if you're into IPv6 hacking, please consider joining the ipv6hackers mailing list: <http://www.si6networks.com/community/mailing-lists.html>. Thanks! Best regards, - -- Fernando Gont SI6 Networks e-mail: fgont(a)si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJRcFgsAAoJEK4lDVUdTnSSbY4QAJQmNVPUzF93uGEGtBiOGDWk f3ccsoaHQnTfXLNM5/qXIGMmT3WBGXTIotaLQKlKqfoEyqPclnKkehoS/gGyw/Vm GfOeNBZaZcAUB+2v57KfmKMxZx9mSk986iWVZwFYLqJ6cLu468WtffavrSw0He7U qjZNBrJ9NDTi2QOVLpRTGgH+pcflnR+EzcHCJIxxKVQL4loqxiPMThjhbi60+JGU bqTJq3jHqAnLxoWBwS0sSPWX6+x4i1HV0w10SuchUD9SWQ194KCcgke97tpa8mwQ YeYKnVls+yjy0ZEt69xgICGdARqASLXmtuwFhHZRTF89DFW2BUAR9KNWvbmRr3ii +JI4vHCWn9naXG6GTuCX1Hhlgi32eTOX9JM+siOMSGcBJRCe+zX/qzL/3rZvkRRb V/cyIXZyoh5/B7fGnR0x4KgPmzblGOURBxh8patxiYuyPW1sRIaF2E+P1XhKRCkn TLUI5Y/H3ZBIyONaIbL857X4qabpxAlNUAYmMmXWK+HMG5QSPWco5T0XMPSipXIO UEuDrr6AsD1rIQwQeyAN1zFasOO5CJx1kCDXWQboFBbub4aABMjmrRH45WAmiexZ kI8DDoLCoiF/f/pJd5nQi37LMDtbB2aF23l/ycWvzGQJ2ijStA7VDlELByqF8Kj2 Q/VoJObsdf6uhB9siNKG =0yAb -----END PGP SIGNATURE-----

1 0

Biggest Fake Conference in Computer Science
by nelsonsteves＠hushmail.com 12 Apr '13

12 Apr '13

We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. If WORLDCOMP is not fake then why did DBLP suddenly stopped listing the proceedings after? The status of your WORLDCOMP papers can be changed from “scientific” to “other” (i.e., junk or non-technical) at any time. See the comments http://www.mail-archive.com/tccc@lists.cs.columbia.edu/msg05168.html of a respected researcher on this. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and threatens the critiques of WORLDCOMP (see Item 7 in Section 5 of http://sites.google.com/site/dumpconf ).That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. WORLDCOMP’13 will be held at a different resort. WORLDCOMP will not be held after 2013. The paper submission deadline for WORLDCOMP’13 was March 18 and it was extended to April 6 and now it is extended to April 20 (it may be extended again) but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Prof. Hamid Arabnia expends the deadline to get more papers (means, more registration fee into his pocket!). Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links.

1 0

New on RIPE Labs: Networks with IPv6 over Time - A Short Update
by Mirjam Kuehne 04 Apr '13

04 Apr '13

Dear colleagues, Please find on RIPE Labs a short update on the percentage of networks announcing IPv6 prefixes: https://labs.ripe.net/Members/emileaben/networks-with-ipv6-over-time-a-shor… Kind regards, Mirjam Kuehne RIPE NCC

1 0