- ipv6-wg - mailman.ripe.net

Measuring long-term effects of World IPv6 Day
by Mirjam Kuehne 05 Jul '11

05 Jul '11

[apologies for duplicates] Dear colleagues, We have been looking at some more long-term effects of World IPv6 Day, held on 8 June. Please find more on RIPE Labs: http://labs.ripe.net/Members/emileaben/measuring-world-ipv6-day-long-term-e… Kind Regards, Mirjam Kuehne RIPE NCC

1 0

Global IPv6 Deployment Monitoring Survey 2011 Now Open
by Paul Rendek 04 Jul '11

04 Jul '11

Dear Colleagues, The Global IPv6 Deployment Monitoring Survey 2011 is now online at: http://www.surveymonkey.com/s/GlobalIPv6survey2011 This survey has been designed by GNKS Consult in collaboration with TNO and the RIPE NCC to further understand where the community stands on IPv6 and what needs be done to ensure that the Internet community is ready for the widespread adoption of IPv6. Anyone can participate in this survey and we hope that the results will establish a comprehensive view of current IPv6 penetration and future plans for IPv6 deployment. The survey comprises 23 questions and can be completed in about 15 minutes. For those without IPv6 allocations or assignments or who have not yet deployed IPv6, there will be fewer questions. The survey will close on 31 July 2011. We thank you for your time and interest in completing this survey. If you have any questions concerning the survey, please email <info(a)gnksconsult.com>. For more information about the survey and links to previous year's survey results, please see: https://www.ripe.net/internet-coordination/news/industry-developments/globa… Regards, Paul Rendek RIPE NCC Head of External Relations and Communication

1 0

New article to RIPE Labs: Measuring World IPv6 Day
by Mirjam Kuehne 28 Jun '11

28 Jun '11

[apologies for duplicates] Dear colleagues, Please find a new articles on RIPE Labs: Measuring World IPv6 Day - Some Glitches and Lessons Learned http://labs.ripe.net/Members/emileaben/measuring-world-ipv6-day-glitches-an… Kind Regards, Mirjam Kuehne RIPE NCC

1 0

IETF working group on renumbering in IPv6
by Shane Kerr 24 Jun '11

24 Jun '11

All, There is some idea to work on the renumbering problem in IPv6. This is certainly of interest to IPv6 folks, but I am including the address policy folks as this may ultimately have impact there. Cheers, -- Shane

2 1

Last 10 Days!: AP2PS 2011 || November 20-25, 2011 - Lisbon, Portugal
by Cristina Pascual 23 Jun '11

23 Jun '11

INVITATION: ================= Note that the submission deadline has been extended to July 1st, 2011. Please consider to contribute to and/or forward to the appropriate groups the following opportunity to submit and publish original scientific results. In addition, authors of selected papers will be invited to submit extended article versions to one of the IARIA Journals: http://www.iariajournals.org ================= ============== AP2PS 2011 | Call for Papers =============== CALL FOR PAPERS, TUTORIALS, PANELS AP2PS 2011: The Third International Conference on Advances in P2P Systems November 20-25, 2011 - Lisbon, Portugal General page: http://www.iaria.org/conferences2011/AP2PS11.html Call for Papers: http://www.iaria.org/conferences2011/CfPAP2PS11.html - regular papers - short papers (work in progress) - industrial presentations - posters - ideas Submission page: http://www.iaria.org/conferences2011/SubmitAP2PS11.html Submission deadline: July 1st, 2011 Sponsored by IARIA, www.iaria.org Extended versions of selected papers will be published in IARIA Journals: http://www.iariajournals.org Please note the Poster Forum and Work in Progress (short papers) options. The topics suggested by the conference can be discussed in term of concepts, state of the art, research, standards, implementations, running experiments, applications, and industrial case studies. Authors are invited to submit complete unpublished papers, which are not under review in any other conference or journal in the following, but not limited to, topic areas. All tracks are open to both research and industry contributions, in terms of Regular papers, Posters, Work in progress, Technical/marketing/business presentations, Demos, Tutorials, and Panels. Before submission, please check and comply with the Editorial rules: http://www.iaria.org/editorialrules.html AP2PS 2011 Topics (topics and submission details: see CfP on the site) Architectures and protocols Search protocols; Publish and subscribe systems; Overlay based multicast; Multilayer systems; Locality awareness; Gossip-based and epidemic protocols; Integration with network operators and service providers; Autonomic computing and networking; Semantic P2P; Opportunistic networking Applications Content delivery networks; Cloud computing; Public resource computing; Aggregate computing; Web services; Computational, service, and storage Grids; Voice and video streaming and IPTV; Collaborative platforms and social networks ; Network management; Wireless sensor networks; Scientific computing and workflow management systems; Green computing Prototypes and simulations Implementations; Comparative performance analysis; Dependability, resilience and availability; Scalability; Stability; Benchmarking and optimization; Quality of experience Security, trust and reputation Privacy & Anonymity; Trust and reputation management; Free-riding prevention; Authentication and identity management; Fairness and Incentive models; Virtual economies; Digital rights management; Content filtering P2P and wireless convergence P2P in cellular networks; P2P in wireless networks; P2P in ad hoc networks; Integrated approaches; Energy efficiency ---------------------- AP2PS General Chairs Nick Antonopoulos, University of Derby, UK Antonio Liotta, Eindhoven University of Technology, The Netherlands Giuseppe Di Fatta, The University of Reading, UK AP2PS Advisory Chairs Marco Aiello, University of Groningen, The Netherlands Takahiro Hara, University of Osaka, Japan Ouri Wolfson, University of Illinois at Chicago, USA AP2PS 2011 Industry Liaison Chair Christoph Schuba, Oracle Corp., USA Roman Y. Shtykh, Rakuten, Inc., Japan AP2PS 2011 Research Chairs Yasushi Kambayashi, Nippon Institute of Technology, Japan Anders Fongen, Norwegian Defense Research Establishment, Norway Quang Hieu Vu, ETISALAT BT Innovation Center (EBTIC)/ Khalifa University, UAE Committee: http://www.iaria.org/conferences2011/ComAP2PS11.html ====================

1 0

Last 10 Days: EMERGING 2011 || November 20-25, 2011 - Lisbon, Portugal
by Cristina Pascual 23 Jun '11

23 Jun '11

INVITATION: ================= Note that the submission deadline has been extended to July 1st, 2011. Please consider to contribute to and/or forward to the appropriate groups the following opportunity to submit and publish original scientific results. In addition, authors of selected papers will be invited to submit extended article versions to one of the IARIA Journals: http://www.iariajournals.org ================= ============== EMERGING 2011 | Call for Papers =============== CALL FOR PAPERS, TUTORIALS, PANELS EMERGING 2011: The Third International Conference on Emerging Network Intelligence November 20-25, 2011 - Lisbon, Portugal General page: http://www.iaria.org/conferences2011/EMERGING11.html Call for Papers: http://www.iaria.org/conferences2011/CfPEMERGING11.html - regular papers - short papers (work in progress) - industrial presentations - posters - ideas Submission page: http://www.iaria.org/conferences2011/SubmitEMERGING11.html Submission deadline: July 1st, 2011 Sponsored by IARIA, www.iaria.org Extended versions of selected papers will be published in IARIA Journals: http://www.iariajournals.org Please note the Poster Forum and Work in Progress options. The topics suggested by the conference can be discussed in term of concepts, state of the art, research, standards, implementations, running experiments, applications, and industrial case studies. Authors are invited to submit complete unpublished papers, which are not under review in any other conference or journal in the following, but not limited to, topic areas. All tracks are open to both research and industry contributions, in terms of Regular papers, Posters, Work in progress, Technical/marketing/business presentations, Demos, Tutorials, and Panels. Before submission, please check and comply with the Editorial rules: http://www.iaria.org/editorialrules.html EMERGING 2011 Topics (topics and submission details: see CfP on the site) Evolution of telecommunications network architectures Advanced communications systems; New configurable protocols stacks and real-time mechanisms; Applications and services for next-generation architectures; Scalability and manageability of network architectures; Opportunistic and cooperative communications; Next generation networks (NGN); Optical networks; Wireless networks, Mobile networks; Ad-Hoc, Sensor, Vehicle networks; Access, Residential, Last mile networks; Home, Body and Personal area Networks; Active networks; Self Organizing networks; Storage area networks; Peer-to-Peer and overlay networks; Network measurements and testbeds; Transmission technologies (e.g., Ultra Wideband) Applications and services Peer-to-Peer applications and services; Web services; Mobile applications; Entertainment and games; Home automation; Surveillance, Home monitoring; Medical and health applications; e-commerce, m-commerce; Location-based services; Real-time and multimedia applications; Real-time services over IP Networking and service differentiation Network design and planning; Network management and control; Traffic engineering; Traffic control, Flow control; Congestion and admission control; QoS support and Performance; Routing, Switching, QoS routing; Mobility management; Multicast; Service reliability, availability Emerging networking Network coding; Visualization of network behavior; Semantic routing; Network flow processing; Cross-layer design and optimization; High-speed networking; Context-aware mobile networking Advanced network elements Network processors; Content addressable memories; Multi-core processors; Context-aware reconfigurable devices; Portable and wearable devices; Mobile multimedia devices Optimization Power optimization in data centers; Delay and fault tolerant networks; Video conferencing and telepresence systems; Resource optimization; Context-aware optimization Quality Quality of service; Quality of performance; Quality of experience; Quality of data; Quality of modeling; Quality-oriented routing; Quality of context /degradation, trust, uncertainty, consistency/ Smartness Cognitive radio; Autonomic and dependable communications; Ambient systems; Identity and location in mobile environments; Smart homes; Brain-like networking and computing Discovery Resource discovery; Service discovery; Content discovery; Flaws/anomaly discovery Protection Anticipative control and management; Data protection strategies; Collaborative Internet attack containment; Micro-kernels and robustness Security Trust and credential negotiations; Privacy; Intrusion prevention and containment; Security in virtualization approach; Architectural support for security; Security, privacy, and dependability; Security in cooperative networks Programmability Programmable and real-time network traffic measurements; Adaptive scheduling; Network and application load balancing; High-performance capabilities-based networks; Software techniques to improve virtualized I/O performance End-user Frequently changing user profile; User mobility and ubiquity; Scalable and resource intensive multi-user distributed applications; User identity and multi-service access technologies; End-user perception; End-user based networking and service orchestration; End-user activity recognition with multiple goals Mobility Mobile Internet services; Mobility-oriented protocols /Mobile IP, etc./; Wearable and/or mobile technologies; Self-discovery and localizing entities; Seamless handover Ubiquity Ubiquitous computing; Pervasive and embedded systems; Ubiquitous sustainability; Sensing location; Activity patterns; Smart environments in the workplaces; Ubiquitous cities Semantics and Adaptiveness Content-aware networks; Network-aware applications; Semantic Web; Adaptive systems; Adaptive applications; Self-adaptiveness; Ontology-based adaptation; Semantic profile; Semantic service orchestration; Multi-technology semantic integration /sensors, ehealth, geosensing, etc./ Wireless Wireless access technologies / WLANs, WiMAX, satellite, 3G, etc./; Multi-hop wireless networks /sensor, ad hoc, mesh, etc./; Wireless QoS and reliability; Wireless body area networks; Energy optimization Emerging technologies and applications Vehicular ad hoc networks; Bio-inspired networks; Tele-medicine/e-health networks; User-centric services and applications; Autonomous and autonomic systems; Self-manageable systems; Emerging computation business models; Social networks; eSociety --------------- EMERGING Advisory Chairs Raj Jain, Washington University in St. Louis, USA Michael D. Logothetis, University of Patras, Greece Tulin Atmaca, IT/Telecom&Management SudParis, France Phuoc Tran-Gia, University of Wuerzburg, Germany Nuno M. Garcia, Universidade Lus�fonas de Humanidades e Tecnologias, Lisboa, Portugal EMERGING 2011 Industry Liaison Chairs Krishna Murthy, Quintiles, USA Tadashi Araragi, Nippon Telegraph and Telephone Corporation � Kyoto, Japan Robert Foster, Edgemount Solutions - Plano, USA EMERGING 2011 Research Chair David Carrera, Barcelona Supercomputing Center (BSC) / Universitat Politecnica de Catalunya (UPC), Spain Committee: http://www.iaria.org/conferences2011/ComEMERGING11.html ====================

1 0

New article on RIPE Labs: Measuring World IPv6 Day
by Mirjam Kuehne 17 Jun '11

17 Jun '11

[apologies for duplicates] Dear colleagues, The RIPE NCC took a number of measurements both before and during World IPv6 Day. We've done an initial analysis of the data and would like to share our first impressions and results with you on RIPE Labs: http://labs.ripe.net/Members/mirjam/measuring-world-ipv6-day-first-impressi… Kind Regards, Mirjam Kuehne RIPE Labs

1 0

v6day.ripe.net
by Robert Kisteleki 08 Jun '11

08 Jun '11

Our dashboard for world IPv6 day is now officially open at http://v6day.ripe.net/ It leads to loads of statistical and diagnostic information. We are still tweaking it a little and adding things. Enjoy Robert

6 9

World IPv6 Day and the RIPE NCC
by Axel Pawlik 08 Jun '11

08 Jun '11

[Apologies for duplicate emails] Dear colleagues, The RIPE NCC is proud to participate in today's World IPv6 Day, a global event in which many organisations around the world are offering their content over IPv6. All of the RIPE NCC’s services and content have already been available over IPv6 for some time. We are also taking part in events in Amsterdam and Moscow, as well as conducting a wide range of IPv6-related measurements and analysis. IPv6 Eye Chart ============== If you want to find out if you will have problems accessing websites during World IPv6 Day, you can use the IPv6 Eye Chart: http://ipv6eyechart.ripe.net/ World IPv6 Day Dashboard ======================== All the IPv6 measurements carried out by the RIPE NCC are available at: http://v6day.ripe.net Amsterdam Event =============== The World IPv6 Day event in Amsterdam features tutorials, workshops, panel discussions and keynote speeches on IPv6. You can follow the event live at: http://webcolleges.uva.nl/mediasite/Viewer/?peid=bee87df6f35d4943adaff2ad98… Moscow Event ============ World IPv6 Day is being celebrated during the RIPE Day at the first meeting of the Eurasia Network Operators Group (ENOG), taking place in Moscow. Throughout the day, there will be IPv6-related presentations, a special meeting for the press and screens tracking the measurements being conducted by the RIPE NCC. A webcast of the event is available at: http://www.enog.org/programme/webcast/ Best regards, Axel Pawlik Managing Director RIPE NCC

1 0

Rapid IPv6 deployment for World IPv6 Day
by Ahmed Abu-Abed 08 Jun '11

08 Jun '11

Hello, To setup a computer with IPv6 public address over any IPv4 connection (3G, ADSL, dial-up, etc. and even behind nested NATs) for World IPv6 Day testing then I suggest downloading the Freenet6 client and running it with default settings; it's the closest you can get to plug and play IPv6. Freenet6 have the TSP protocol IPv6 server in Amsterdam, so response times should be acceptable. Only the Windows XP/Vista/7 versions have an intuitive graphical interface, while OS X, BSD and Linux are command line only so far. Register and download the client from http://gogonet.gogo6.com/page/freenet6-ipv6-services Its working very well at my end today, with standard pings to Facebook, Bing, Yahoo and Google defaulting to IPv6 addresses and responses when connected to Freenet6. Regards, -Ahmed

1 0

IPv6 World Day prep behind a crappy hotel DNS resolver
by Shane Kerr 07 Jun '11

07 Jun '11

Hello, IPv6 World Day is tomorrow! I'm at the ENOG meeting in Moscow, which has a pretty common hotel Internet setup - a web redirect on first connect and then some magic somewhere records your information so you get out to the Internet more-or-less directly from then on. Someone at the meeting was kind enough to set up IPv6 service here. Yesterday it seemed a bit bumpy, but today it is working nicely. However, the network has a somewhat broken DNS resolver, which is also sadly pretty common at hotels. It seems to have problems answering normal IPv4 address queries (A records), but mostly works for that. It does not handle IPv6 address queries (AAAA records) at all. :( I tried running a resolver on my laptop, but the hotel network restricts DNS UDP packets to a maximum of 512 bytes. Even worse, it truncates larger answers to that size, and does not set the truncate bit. This confuses BIND mightily, as you would expect, since it is basically getting corrupted packets. Plus it blocks DNS TCP completely. Suffice it to say IPv4 is damaged here. A quick Google reveals that OpenDNS has IPv6 servers, which allows me to use the IPv6 transit, which is free of nonsensical tampering: http://warrenkwok.blogspot.com/2011/05/opendns-offers-ipv6-resolvers.html The IPv6 eyechart is now a sea of green! I'm ready for tomorrow. Are you? :) -- Shane

1 0

Asymmetric 6to4 measurements
by Mirjam Kuehne 06 Jun '11

06 Jun '11

[apologies for duplicates] Dear colleagues, In preparation for World IPv6 Day, Richard Barnes and Emile Aben have been working on measuring the impact of 6to4 on the latency of Internet traffic. This new article on RIPE Labs describes the measurement techniques and some initial findings: http://labs.ripe.net/Members/rbarnes/world-ipv6-day-asymmetric-6to4-measure… Kind Regards, Mirjam Kuehne RIPE NCC

1 0

New article on RIPE Labs: Experimental NAT64/DNS64 Service at LITNET
by Mirjam Kuehne 01 Jun '11

01 Jun '11

Dear colleagues, The Lithuanian research and education network LITNET and the Kaunas University of Technology provide an experimental NAT64/DNS64 service. Please find more information on RIPE Labs: http://labs.ripe.net/Members/raimis/experimental-nat64-dns64-service Kind regards, Mirjam Kuehne RIPE NCC

1 0

How DNS caching affects the start of World IPv6 Day
by Mirjam Kuehne 31 May '11

31 May '11

[apologies for duplicates] Dear colleagues, Please find a new article on RIPE Labs showing how DNS caching affects the start of World IPv6 Day and how World IPv6 Day participants can minimise these effects: http://labs.ripe.net/Members/emileaben/when-does-world-ipv6-day-start Kind regards, Mirjam Kuehne RIPE NCC

1 0

IPv6 on P2P links
by Jasper Jans 30 May '11

30 May '11

Can anyone give me some real world experience with IPv6 numbering on P2P links in their network? I've seen the recommendations swing from '/64' to '/127 if your equipment can handle it' and even to 'do not assign anything at all just use link-local' and access your devices over the loopback which your IGP will distribute. The last option seems interesting to me from a IP assignment point of few. It safes me having to allocate a block for this part of the infrastructure. I'm just wondering if in the long run it will not make life harder. Jasper Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.espritxb.nl/disclaimer

13 26

Test your connectivity for World IPv6 Day
by Mirjam Kuehne 27 May '11

27 May '11

Dear colleagues, The RIPE NCC is preparing some measurements for World IPv6 Day. One of them is the IPv6 eye chart, a web page that allows you to test your connectivity to selected dual-stacked web sites and World IPv6 participants. The goal is to see if an end user has connectivity problems to dual-stacked websites. You can read more on RIPE Labs: http://labs.ripe.net/Members/emileaben/world-ipv6-day-ipv6-eye-chart The test can be found here: http://ipv6eyechart.ripe.net/ If you have any questions or want to be included in the test, please contact us at labs at ripe dot net. Kind Regards, Mirjam Kuehne RIPE NCC

1 0

RE: [ipv6-wg] IPv6 on P2P links
by Elad Hefetz 26 May '11

26 May '11

The major problem I can assume happen when using only link local is the issue of replacing hardware. When you replace the cards on the routers it will require you to change the internal routing protocol (IS-IS \ OSPF). Another issue is debugging - when using trace route - all you will see is link-local addresses which make it very difficult to debug issues. We are configuring all our P2P links with /64 prefix on each link. This is not idle and very wasteful way, but it's the only solution to not interfere with RFCs and standards. Also - this is the only way to be multi vendors prepared, be ready for future to come with new IPv6 applications and products. MHO, Elad -----Original Message----- From: ipv6-wg-admin(a)ripe.net [mailto:ipv6-wg-admin@ripe.net] On Behalf Of Jasper Jans Sent: Thursday, May 26, 2011 11:08 AM To: ipv6-wg(a)ripe.net Subject: [ipv6-wg] IPv6 on P2P links Can anyone give me some real world experience with IPv6 numbering on P2P links in their network? I've seen the recommendations swing from '/64' to '/127 if your equipment can handle it' and even to 'do not assign anything at all just use link-local' and access your devices over the loopback which your IGP will distribute. The last option seems interesting to me from a IP assignment point of few. It safes me having to allocate a block for this part of the infrastructure. I'm just wondering if in the long run it will not make life harder. Jasper Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.espritxb.nl/disclaimer

2 1

Announcement: RIPE NCC Training Courses
by Training Mailbox 23 May '11

23 May '11

[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/lir-services/training/courses/lir/outline/ - 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/lir-services/training/courses/rr/ - 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 <training(a)ripe.net>. Kind regards, Rumy Kanis Training Services Manager RIPE NCC

1 0

IPv6 CPE Survey - Initial Results on RIPE Labs
by Mirjam Kuehne 23 May '11

23 May '11

[apologies for duplicates] Dear colleagues, Since we published the IPv6 customer premise equipment (CPE) survey during the RIPE 63 meeting, we received more than 100 responses. This new article on RIPE Labs shows some interesting initial results: http://labs.ripe.net/Members/marco/ipv6-cpe-survey-results-may-2011 The survey is still open. If you are using an IPv6 capable CPE and have not yet filled in the survey, we would like to encourage you to do so. The survey can be found here: http://labs.ripe.net/Members/marco/ipv6-cpe-survey-please-participate Kind Regards, Marco Hogewoning & Mirjam Kuehne RIPE NCC

1 0

IPv6 filtering in an ISP environment
by Erik Bais 18 May '11

18 May '11

Hi, I'm looking for examples on what people have implemented as ingress filtering for IPv6 prefixes in an BGP environment. I'm would like to get some sort of filter that will not require daily maintenance based on assigned prefixes by the RIR. I'm leaning towards having some sort of filtering based on: Drop anything from bogon list allow RIR PA space - between /12 - /35 Allow RIR PI space between /32 - /48. (For instance for the RIPE 2001:67c::/32 & 2001:7f8::/32 parts ) So basically, a bit more strict filter than allow 2003::/3 and not having to update it daily with each assignment made J Also some insight in why you have selected to filter on a specific prefix length is very helpful. Erik Bais

5 6

Thought for World IPv6 Day
by Martin Millnert 18 May '11

18 May '11

Hi, I'm thinking that in order for maximizing productive yield of World IPv6 Day as IPv6-believers would like, laying out the relevant steps to take for ISPs, content providers and individual users in a pedagogical manner could be cool (i.e highly useful). I'm imagining something similar to what Google did with http://www.google.com/googlebooks/chrome/index.html for Chrome. I have no idea who would be in charge to bring that about, or if it is at all possible to achieve in the few days left. I hope others are better suited to answer this. Cheers, Martin

4 5

RIPE NCC Measurements for World IPv6 Day
by Mirjam Kuehne 11 May '11

11 May '11

[apologies for duplicates] Dear colleagues, Please find on RIPE Labs a description of the measurements the RIPE NCC is doing prior to and on World IPv6 Day: http://labs.ripe.net/Members/emileaben/ripe-ncc-measurements-for-world-ipv6… This is an extended version of the presentation Emile Aben gave in the MAT-WG at RIPE62. Feedback received at the meeting, has been incorporated. Please also note the call for participation for each of the measurements described in the article. If you have any other feedback or questions, please do not hesitate to contact us at labs(a)ripe.net. Kind Regards, Mirjam Kuehne RIPE NCC

1 0

IPv6 RIPEness - One Year later
by Mirjam Kuehne 04 May '11

04 May '11

[apologies for duplicates] Dear colleagues, A year ago we introduced IPv6 RIPEness - a system that rates IPv6 deployment of Local Internet Registries based on certain criteria. Now, one year later, we were curious to see how the numbers have changed. Please read the update on RIPE Labs: http://labs.ripe.net/Members/becha/ipv6-ripeness-one-year-later Kind Regards, Mirjam Kuehne RIPE NCC

1 0

IPv6 theme day on RIPE 62
by Marco Hogewoning 03 May '11

03 May '11

Dear colleagues, For those of you who missed out on the original announcement and who are wondering why we haven't published an agenda yet. The upcoming RIPE Meeting does not have a formal seating of the IPv6 Working Group. Given the amount of content and the current state of affairs, the collective chairs decided to dedicate a full day to the topic. So Tuesday's plenary session will be all about IPv6, covering a broad range of topics. We have talks about the state of the world, overviews of the available transitioning techniques and various presentations from people who already deployed IPv6 in their network. We are still busy with the final details of the agenda and the time schedule, but this is what we already have scheduled: Dynamic IPv4 Address Release - Olaf Bonness Transition Technologies Overview - Marco Hogewoning IPv6 Mobility in Emergency Teams - Jan Žorž RIPE 501 bis - Jan Žorž et al IPv6 Routing Table Update - Gert Döring IPv6 Deployment Real Case - Ragnar Anfinsen (Altibox Norway) IPv6 Issues on AMS-IX Peering LAN - Arien Vijn Deploying IPv6 Without Huge Costs – Case Study IPv6 Geolocation - TBD IPv6 Pending Badge Initiative - INEX IPv6 CPE survey: Initial results - Mirjam Kuehne As stated we are still busy with the final details and some speakers, for the latest updates please refer to the meeting plan at http://ripe62.ripe.net/programme/meeting-plan/plenary For those who can't make it to Amsterdam, all the sessions will be broadcasted on the Internet and available for remote participation. Details for the webcast will be posted on http://ripe62.ripe.net, session will start at 09:00 CEST. For those coming to the meeting, save travels and see you next week, The IPv6 Working Group co-chairs. Marco, Shane and David Grtx, MarcoH

3 4

Announcement: New IPv6 information videos available now
by Nathalie Trenaman 28 Apr '11

28 Apr '11

Dear Colleagues, The RIPE NCC is pleased to announce the launch of four new information videos on real-life IPv6 deployment experiences. The following videos are now available in the RIPE NCC's E-Learning Centre at: http://www.ripe.net/lir-services/training/e-learning/ipv6 - Jan Žorž talks about "Mobile IPv6" - Tore Anderson gives an overview on "IPv6 and Content Providers" - Nuno Viera talks about "IPv6 in Hosting Environments" - Teun Vink is interviewed about "IPv6 and ISPs" The RIPE NCC E-Learning Centre is free and available to everyone. If you have any questions about this, please contact us at <e-learning(a)ripe.net>. Regards, Nathalie Trenaman Trainer RIPE NCC

1 0

New IPv6 survey released on labs.ripe.net
by Marco Hogewoning 27 Apr '11

27 Apr '11

Hi There, We just released a new version of the IPv6 CPE survey. After lots of feedback on the previous editions, we are now doing a "proper" survey. Based on the responses we receive in this survey we will be able to compile a new edition of our matrix and provide some more statistical background on what is happening in the market. Remember we are totally depending on your feedback to continue this work. The more responses we receive, the easier it gets for us to provide regular updates on which CPE are available on the market and how good they are. So if you have an IPv6 capable router or modem in your house, or you are busy testing them. Please take the time to fill out the survey and help other people to find the device that fits their need. Please see https://labs.ripe.net/Members/marco/ipv6-cpe-survey-please-participate for further details and a link to the survey. Thanks, MarcoH

1 0

Request: IPv6 day preparations
by David Kessens 21 Apr '11

21 Apr '11

Hi, I was wondering whether there is anybody on this list who might be willing and/or knows somebody who can speak at the next RIPE meeting regarding ongoing preparations for the IPv6 day in June: http://isoc.org/wp/worldipv6day/ Specifically, are there any people who are for example preparing their customer service department and other parts of the company as opposed to just moving the main website to ipv6. Are there any problems you expect ? Or, other things that deserve attention ? Please respond to: ipv6-wg-chairs(a)ripe.net Thanks, David Kessens ---

1 0

New article on RIPE Labs: Testing Teredo
by Mirjam Kuehne 20 Apr '11

20 Apr '11

Dear colleagues, Please see a new interesting article on RIPE Labs: Testing Teredo by Geoff Huston: http://labs.ripe.net/Members/gih/testing-teredo Kind Regards, Mirjam Kuehne RIPE NCC

1 0

FYI: APNIC has activated their final /8 policy
by Marco Hogewoning 18 Apr '11

18 Apr '11

Dear Colleagues, As you may have already seen on other mailing lists, APNIC, the Regional Internet Registry for the Asian Pacific region, has reached the end of their pool of available IPv4 addresses. As of Friday April 15, they have activated their "final /8" policy, which was decided upon by the APNIC community [1]. This event in itself does not have any effect on the amount of IPv4 addresses which are still available within the RIPE NCC service region. But we would like to remind you that eventually the RIPE community will have to deal with the same situation. We would like to point out that he RIPE community has decided that an LIR must already have IPv6 addresses before they become eligible for their final allocation under the final /8 policy. This requirement is in addition to having a demonstrated need for address space. For more information about this, please refer to section 5.6 of the IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region [2]. We would like to urge the community to start deploying IPv6 as soon as possible if they haven't done so already. This is the only way to support the long-term growth of the Internet and ensure the continuity of their operations. And if you have already deployed IPv6 in your network, please share your experiences for others to learn from. Greetings, The IPv6 working group chairs, Marco, David & Shane [1] http://www.apnic.net/publications/news/2011/final-8 [2] http://www.ripe.net/ripe/docs/ripe-509

1 0

RIPE IPv4 Pool Graph
by Ahmed Abu-Abed 06 Apr '11

06 Apr '11

Greetings, RIPE NCC is now publishing an IPv4 pool graph with weekly updates, and the latest data show five /8 blocks are remaining. More at http://www.ripe.net/internet-coordination/ipv4-exhaustion/ipv4-available-po… Regards, -Ahmed

1 0

Is there a recommended list for sharing IPv6 deployment experience/woes/etc?
by Niall O'Reilly 29 Mar '11

29 Mar '11

A colleague in the Irish IPv6 TF was asking, and I couldn't think of just the right list. The kind of sharing of operational experience he's looking for doesn't seem to me to fall quite within the scope of the RIPE IPv6 WG list, and certanly not within the IETF v6ops list. I'll be glad to find I'm mistaken, or else to have suggestions ... Thanks in advance. Niall Begin forwarded message: > From: Gavin McCullagh <gavin.mccullagh(a)gcd.ie> > Date: 29 March 2011 12:02:46 GMT+01:00 > To: Irish IPv6 Task Force <ipv6tf(a)listserv.tssg.org> > Subject: [Ipv6tf] spoofed router advertisements > Reply-To: Gavin McCullagh <gavin.mccullagh(a)gcd.ie> > > > Hi folks, > > I realise this isn't a list for practical details of running IPv6, but is > there a list people do recommend? > > For some time now, on and off, we've been noticing bogus IPv6 router > advertisements, presumably from student laptops. [...]

6 6

New on RIPE Labs: 6to4 - Why is it so Bad?
by Mirjam Kuehne 21 Mar '11

21 Mar '11

[apologies for duplicates] Dear colleagues, In an earlier article on RIPE Labs, we showed that a large percentage of 6to4 connections fail. In this new article by Emile Aben, we look at why these connections fail and what can be done about this: http://labs.ripe.net/Members/emileaben/6to4-why-is-it-so-bad Kind Regards, Mirjam Kuehne RIPE NCC

1 0

Re: ipv6-wg -- confirmation of subscription -- request 440625
by Henk Uijterwaal 15 Mar '11

15 Mar '11

confirm 440625

1 0

"Preparing an IPv6 Addressing Plan" - New Manual Published on www.ripe.net
by Nathalie Trenaman 15 Mar '11

15 Mar '11

Dear colleagues, The RIPE NCC has just published "Preparing an IPv6 Addressing Plan", an easy-to-read manual to help End Users effectively distribute large blocks of IPv6 address space over their networks. The document is available for download here: http://www.ripe.net/training/material/IPv6-for-LIRs-Training-Course/IPv6_ad… The manual was written by Sander Steffann and Surfnet. It has been translated from Dutch to English by the RIPE NCC. If you have any feedback about the manual, please send it to: <nathalie(a)ripe.net> Kind Regards, Nathalie Trenaman RIPE NCC Trainer

1 0

Re: [address-policy-wg] IPv6 allocations for 6RD
by Ahmed Abu-Abed 28 Feb '11

28 Feb '11

Greetings, Compared to 6RD, the TSP protocol (RFC 5572) can also rapidly deploy IPv6, needing one /32 allocation while customer site prefixes can be /64, /56 or /48. Reason is TSP doesn't embed the customer's IPv4 address in its IPv6 address as 6RD does. Being a hot topic nowadays, its worth mentioning customer site access gear (CPE) requirements are more relaxed with TSP as it doesn't need the Service Provider IPv4-only access modem to be changed or upgraded. A TSP client can run in a small hardware device (thru an Ethernet interface connection) or a software client in the home network behind the SP modem while enabling all v6 capable nodes with the assigned prefix by automatically establishing a tunnel to the SP TSP tunnel server. Since TSP allows for static prefix assignment and larger prefixes than /64 without wasting v6 space, this would mimic a native deployment more closely. The stateful tunneling could be seen as any other encapsulation in the access, and a few service providers have it running already. In the long term, both 6RD and TSP will give way to reverse tunneling i.e. v4-in-v6, as this is the only way (after IPv4 depletion) for both protocols to co-exist on a host while having a mix of v4-only and dual-stack accessible services/website. Reverse tunneling's current protocols, DS-Lite and DSTM, are very similar to TSP's concept so the same clients & servers supporting TSP can be adapted to support DS-Lite. Unfortunately, until IPv4 disappears from web content, hosts and servers these coexistence mechanisms will be needed. Regards, -Ahmed From: Kurt Smolderen Sent: Monday, February 28, 2011 11:13 AM To: address-policy-wg(a)ripe.net Subject: RE: [address-policy-wg] IPv6 allocations for 6RD I strongly support the idea of assigning a smaller prefix to ISPs which are in a state of deploying IPv6 but need to use transitional mechanism for (some of) their customers. Mark has described one of the problems very clear in his email: if an ISP has only a /32 prefix and needs to use all 32 IPv4 bits in the 6rd configuration, only a /64 can be delivered to the home instead of the desired /56 or /48. Needing all 32 bits is for instance the case when an ISP offers internet connectivity to some of its customers via a partnership with another ISP. However, I want to point to an additional problem which appears when an ISP wants to deploy native IPv6 but needs to roll out 6rd (or any other transitional technique) as well. For native IPv6, the ISP will create an IPv6 addressing plan. This will normally include separate prefixes for the ISP's own servers, the ISP's backbone, the ISP's customers etc. For the 6rd domain, the full /32 range is however needed. So at this stage, the ISP has two options: 1) Implement 6rd only 2) Implement native IPv6 only and exclude some customers from being able to use IPv6 (those which would normally be connected through 6rd) I strongly believe we all agree 6rd is only a temporary solution. So I can't imagine we would prefer skipping native IPv6 deployments in favor of IPv6 transitional mechanisms. I also believe we all agree we should enable IPv6 for as much customers as we can, which makes me conclude the second 'option' is not really an option at all... My primary concern is that any ISP - regardless of how small or big it is - can independently of other organizations/ ISPs move forward with IPv6 deployment. RIPE can support this by adapting a policy which - albeit for a limited time span - allows the assignment of a contiguous IPv6 prefix which size does not only depend on the amount of customers the ISP has, but also incorporates the needed technologies to 'IPv6-enable' as much customers as possible. Regards, -Kurt

2 1

Benefits of IPv4 exhaustion
by Shane Kerr 25 Feb '11

25 Feb '11

All, As seen in today's xkcd: http://xkcd.com/865/ Happy Friday everyone! -- Shane

1 0

Fwd: [routing-wg] IPv6 Routing Recommendations.
by Rob Evans 24 Feb '11

24 Feb '11

Good people of the IPv6 Working Group, It was suggested to me that for some strange reason you may also be interested in this document and discussion... Best regards, Rob -------- Original Message -------- Subject: [routing-wg] IPv6 Routing Recommendations. Date: Wed, 23 Feb 2011 14:39:18 +0800 From: Rob Evans <rhe(a)nosc.ja.net> To: routing-wg(a)ripe.net All, You may remember that back in the mists of time (about a year ago) we had a document that updated RIPE-399 with some IPv6 routing recommendations. After the meeting last May, the authors were to go away and take out mention of any specific suggestions on filtering (e.g. /36). Over the past 12 months, Philip and I have been hard at work constantly refining this document to reflect the changing nature of the IPv6 routing table. Well, kind-of. Anyway, my laziness aside, appended is the document as it stands at the moment. Comments and discussion please! Rob RIPE Routing Working Group Recommendations on IPv6 Route Aggregation ==================================================================== Rob Evans Philip Smith Introduction ============ Recent discussion has shown there is a limited requirement to be able to advertise more specific prefixes from an IPv6 Provider Aggregatable (PA) allocation where a Local Internet Registry (LIR) contains several networks which are not interconnected, or for traffic engineering purposes. This document recommends such advertisements are limited in both length and scope. It is intended to supplement the working group's Recommendations on Route Aggregation [RIPE-399]. Background ========== The IPv6 address allocation and assignment policy for the RIPE region [V6-ALLOC] only allows LIRs to obtain more than the minimum PA allocation if they can demonstrate address utilisation that requires it. This fits with the address space management principle of conservation. However, as understood in the RIPE Routing Working Group's Recommendations on Route Aggregation [RIPE-399], there are occasionally requirements for the advertisement of more specific routes from within an allocation. With a few ISPs currently filtering at the minimum PA allocation (/32) within the relevant address ranges, this can cause significant difficulties for some networks wishing to deploy IPv6. Some reasons for wanting to advertise multiple prefixes from a PA allocation could be: - The LIR has several networks that are not interconnected. - Traffic engineering: A single prefix that covers an LIR's entire customer base may attract too much traffic over a single peering link This document is only concerned with IPv6 Provider Aggregatable (PA) allocations, and does not discuss Provider Independent (PI) prefixes. Recommendation ============== It is suggested that prefix filters allow for prudent subdivision of an IPv6 allocation. The operator community will ultimately decide what degree of subdivision is supportable, but the majority of ISPs accept prefixes up to a length of /48 within PA space. Advertisement of more specific prefixes should not be used unless absolutely necessary and, where sensible, a covering aggregate should also be advertised. Further, LIRs should use BGP methods such as NO_EXPORT [RFC-1997], [AS-PATHLIMIT], or provider-specific communities, as described in [RIPE-399] to limit the propagation of more specific prefixes in the routing table. Discussion ========== There is a valid need for some LIRs to advertise more than one IPv6 PA prefix. As either obtaining more address space and advertising more /32 prefixes, or advertising more specific prefixes within an already allocated /32 have the same impact on the routing table, it is suggested that the latter approach is taken to prevent address space wastage. It is understood that this may not cover all possibilities. There may be circumstances where sites will have to consider the suitability of Provider Independent addresses, or LIRs may have to consider mechanisms of obtaining more than a /32 of Provider Aggregatable space. References ========== [V6-ALLOC] http://www.ripe.net/ripe/docs/ipv6policy.html [RIPE-399] http://www.ripe.net/ripe/docs/ripe-399 [RFC-1997] http://www.rfc-editor.org/rfc/rfc1997.txt [AS-PATHLIMIT] http://tools.ietf.org/html/draft-ietf-idr-as-pathlimit-03 Work in Progress.

1 0

Announcement: RIPE NCC Training Courses
by Training Mailbox 22 Feb '11

22 Feb '11

[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/lir-services/training/courses/lir/outline/ - 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/lir-services/training/courses/rr/ - 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 <training(a)ripe.net>. Kind regards, Rumy Kanis Training Services Manager RIPE NCC

1 0

RIPE 62 working group session
by Marco Hogewoning 22 Feb '11

22 Feb '11

Dear Colleagues, Registration for the RIPE 62 meeting, which takes place from 2 till 6 May in Amsterdam (NL). As you may have noticed the IPv6 working group is missing from the meeting plan. This is not an error, but an intentional change to the agenda. After some discussion with the working group chairs collective and other stakeholders, we concluded that the IPv4 run out and the associated need to deploy IPv6 will most likely be a very hot topic on this upcoming meeting. It has therefor been decided that the time originally allocated for our working group would be added to the plenary program. Any interesting IPv6 topics, and I'm sure there are many, will be placed in the plenary schedule. At the same time, the closing plenary on Friday morning will host a "IPv6 roundup". In this session we will discuss the outcome of the meeting, based on input received from the working groups and presentations or comments during the plenary sessions. In other words, no need to panic. The IPv6 working group will be present, although not in a formal setting this time. If you have any interesting information on IPv6 deployment, interactions between IPv4 and IPv6 and deployment of transitioning techniques. Please consider presenting about it on this meeting and send a short description of what you like to present together with your contact details to ipv6-wg-chairs at ripe dot net. See you in Amsterdam, The IPv6 working group chairs, Marco, Shane and David.

1 0

Registering IPv6 Assignments in the RIPE Database
by Denis Walker 15 Feb '11

15 Feb '11

[Apologies for duplicate emails] Dear Colleagues The RIPE community recently approved RIPE Policy Proposal 2010-06, "Registration Requirements for IPv6 End User Assignments". The proposal is available at: [http://www.ripe.net/ripe/policies/proposals/2010-06] This has now been implemented in the RIPE Database and other RIPE NCC processes, where necessary. Details of how to use the new aggregation feature of the RIPE Database can be found at: http://www.ripe.net/data-tools/support/documentation/documenting-ipv6-assig… For those who have already made some IPv6 assignments, you will need to document them in the RIPE Database according to the policy if you have not already done so. All new IPv6 assignments must be registered in the RIPE Database in accordance with this policy. Regards, Denis Walker Business Analyst RIPE NCC Database Group

1 0

2010-06 Proposal Accepted (Registration Requirements for IPv6 End User Assignments)
by emadaio＠ripe.net 10 Feb '11

10 Feb '11

Dear Colleagues, Consensus has been reached, and the proposal described in 2010-06 has been accepted by the RIPE community. The updated policy "IPv6 Address Allocation and Assignment Policy" is available at: http://www.ripe.net/ripe/docs/ripe-512 The new policy "Value of the "status:" and "assignment-size:" attributes in inet6num objects for sub-assigned PA space" is available at: http://www.ripe.net/ripe/docs/ripe-513 You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2010-06 Thank you for your input. Regards Emilio Madaio Policy Development Officer RIPE NCC

1 0

FWD: IANA Allocates Two /8s of IPv4 Space to APNIC
by David Kessens 02 Feb '11

02 Feb '11

----- Forwarded message from Axel Pawlik <no-reply(a)ripe.net> ----- Date: Tue, 01 Feb 2011 05:27:16 +0100 From: Axel Pawlik <no-reply(a)ripe.net> To: ripe-list(a)ripe.net, ncc-announce(a)ripe.net, ncc-services-wg(a)ripe.net Subject: IANA Allocates Two /8s of IPv4 Space to APNIC Reply-To: no-reply(a)ripe.net [Apologies for duplicate emails] Dear colleagues, On 1 February 2011, the IANA allocated two /8s of IPv4 address space to APNIC, the Regional Internet Registry (RIR) for the Asia Pacific region. This means that only five /8s of IPv4 address space are left in the IANA free pool and the "Global Policy for the Allocation of the Remaining IPv4 Address Space" will be triggered. This policy can be found online at: http://www.icann.org/en/general/allocation-remaining-ipv4-space.htm When this policy comes into effect, the five RIRs will each receive one of the five remaining /8s and the global IPv4 pool will be exhausted. We expect IANA to allocate these final /8s within the next few days. For further information please see: http://www.ripe.net/v4exhaustion/ Regards, Axel Pawlik Managing Director RIPE NCC ----- End forwarded message -----

1 0

[sunny@apnic.net: [apops] Two /8s allocated to APNIC from IANA (39/8 and 106/8)]
by David Kessens 01 Feb '11

01 Feb '11

----- Forwarded message from Srinivas Chendi <sunny(a)apnic.net> ----- Date: Tue, 01 Feb 2011 09:20:41 +1000 From: Srinivas Chendi <sunny(a)apnic.net> To: apops(a)apops.net Subject: [apops] Two /8s allocated to APNIC from IANA (39/8 and 106/8) _______________________________________________________________________ Two /8s allocated to APNIC from IANA (39/8 and 106/8) _______________________________________________________________________ Dear Colleagues The information in this announcement is to enable the Internet community to update network configurations, such as routing filters, where required. APNIC received the following IPv4 address blocks from IANA in February 2011 and will be making allocations from these ranges in the near future: 39/8 106/8 Reachability and routability testing of the new prefixes will commence soon. The daily report will be published at the usual URL: http://www.ris.ripe.net/debogon Please be aware, this will be the final allocation made by IANA under the current framework and will trigger the final distribution of five /8 blocks, one to each RIR under the agreed "Global policy for the allocation of the remaining IPv4 address space". http://www.icann.org/en/general/allocation-remaining-ipv4-space.htm After these final allocations, each RIR will continue to make allocations according to their own established policies. APNIC expects normal allocations to continue for a further three to six months. After this time, APNIC will continue to make small allocations from the last /8 block, guided by section 9.10 in "Policies for IPv4 address space management in the Asia Pacific region". This policy ensures that IPv4 address space is available for IPv6 transition. http://www.apnic.net/policy/add-manage-policy It is expected that these allocations will continue for at least another five years. APNIC reiterates that IPv6 is the only means available for the sustained ongoing growth of the Internet, and urges all members of the Internet industry to move quickly towards its deployment. Kind regards, _______________________________________________________________________ APNIC Secretariat secretariat(a)apnic.net Asia Pacific Network Information Centre (APNIC) Tel: +61 7 3858 3100 PO Box 3646 South Brisbane, QLD 4101 Australia Fax: +61 7 3858 3199 6 Cordelia Street, South Brisbane, QLD http://www.apnic.net _______________________________________________________________________ * Sent by email to save paper. Print only if necessary. _______________________________________________ apops mailing list apops(a)apops.net http://mailman.apnic.net/mailman/listinfo/apops Website: www.apops.net ----- End forwarded message -----

1 0

Re: [ipv6-wg] 2010-06 is going to Last Call
by David Kessens 28 Jan '11

28 Jan '11

[ Courtesy copy sent to address policy and database working groups. Please follow up on the ipv6-wg list. ] All, We have not received any input so far whether you support draft policy 2010-06. While silence will in general be interpreted as consensus, we prefer to have a good number of statements of support as that will make it unequivocally clear that consensus was indeed reached. The last call period will end 2010-02-03 (Thursday, 3 February 2011). Please e-mail any final comments to ipv6-wg(a)ripe.net before then. Thanks, David & Shane --- On Thu, Jan 06, 2011 at 02:20:25PM +0100, Shane Kerr wrote: > Hello, > > [ Courtesy copy sent to address policy and database working groups. Please > follow up on the ipv6-wg list. ] > > The Review Phase for the RIPE policy proposal 2010-06 ended on > 2010-12-27 (Monday, 27 December 2010). > > You can see the policy proposal here: > > http://ripe.net/ripe/policies/proposals/2010-06.html > > There were some clarifications during the Review Phase, but nothing > indicating changes needed. > > David and I have decided that the proposal is ready for a Last Call. (As > co-author of the proposal, Marco has recused himself from any consensus > judgments.) > > The last call period is four weeks, so will end 2010-02-03 (Thursday, 3 > February 2011). Please e-mail any final comments to ipv6-wg(a)ripe.net > before then. > > Thanks, > > -- > Shane

26 35

Proposed Implementation Plan for Policy Proposal 2010-06 in the RIPE Database
by Denis Walker 26 Jan '11

26 Jan '11

[Apologies for duplicate emails] Dear Colleagues, To prepare for the possible acceptance of RIPE Policy Proposal 2010-06, "Registration Requirements for IPv6 End User Assignments", the Database Group at the RIPE NCC proposes the following implementation plan. We will implement a new attribute ("assignment-size:") in INET6NUM objects, add some business logic for its use and add a new value (AGGREGATED-BY-LIR) for the "status:" attribute of an INET6NUM object. Schema and syntax changes in INET6NUM objects: - New attribute "assignment-size:" - Syntax is numeric value > 0 - INET6NUM object will include "assignment-size:" as an optional, single attribute - "assignment-size:" will not be an inverse searchable attribute - New value for the "status:" attribute of an INET6NUM object will be AGGREGATED-BY-LIR Business rules: - "assignment-size:" is optional in INET6NUM objects but required if "status:" is AGGREGATED-BY-LIR - The value of "assignment-size:" must be greater than the prefix size of the INET6NUM object containing the attribute - Parent status of INET6NUM object with status AGGREGATED-BY-LIR can be: ALLOCATED-BY-RIR ALLOCATED-BY-LIR AGGREGATED-BY-LIR - If parent status is AGGREGATED-BY-LIR, grandparent status cannot be AGGREGATED-BY-LIR - If an object has the status AGGREGATED-BY-LIR, a more specific object can only have the status AGGREGATED-BY-LIR (subject to the aforementioned constraints) We will prepare implementation of this plan during the week commencing 31 January 2011. It will be deployed during the week commencing 7 February 2011 should RIPE Policy Proposal 2010-06 be formally approved. Regards, Denis Walker Business Analyst RIPE NCC Database Group

1 0

Future of the IPv6 CPE survey - Your Input Needed
by Mirjam Kuehne 24 Jan '11

24 Jan '11

[apologies for duplicates] Dear colleagues, Based on new information we received since the last publication, we updated the IPv6 CPE matrix: http://labs.ripe.net/Members/mirjam/ipv6-cpe-survey-updated-january-2011 In order to make this information more useful for a large user base, we are preparing a detailed survey to gather more structural feedback about the range of equipment that is currently in use. Not only would we like you to participate in this survey, but we also ask you for help in identifying the right survey questions. Please find a call for input on RIPE Labs: http://labs.ripe.net/Members/marco/future-of-the-ipv6-cpe-survey-more-input… Kind Regards, Mirjam Kuehne & Marco Hogewoning RIPE NCC

1 0

Tool for /8 remaining
by Ahmed Abu-Abed 22 Jan '11

22 Jan '11

Greetings, Does RIPE have any tool to indicate the remaining /8s , or portion thereof, in its own pool ? APNIC has a good one with recent history, see http://www.apnic.net/community/ipv4-exhaustion/graphical-information Regards, -Ahmed

1 0

And the IANA ipv4 depletion-day is ... yesterday ????
by Kristoff Bonne 21 Jan '11

21 Jan '11

Hi, An interesting piece of news on the "ipv6depletion" website: http://www.ipv4depletion.com/?p=557#comments Because of two large delegations of the APNIC to two Chinese ISPs, the IANA depletion-day is moving real close. In fact, based on the rumours in the last comment, it has actually already happening but the IANA is holding back the allocation of the two last IANA "non-final" /8 blocks to APNIC for a couple of days to plan for a major media-event. (which - I guess- will not happen on a friday; so probably early next week). So, this leads us to the next question: What about a predection for the RIPE ipv4-depletion day? According the "bye-bye ipv4" applet I have running, the RIPE-pool currently has some 10.7 % still free: 279835 /24 left before the "final-/8" rules become to play. Any prediction how far we are from that point? Cheerio! Kr. Bonne.

1 0

The RIPE NCC's involvement in the World IPv6 Day
by Mirjam Kuehne 19 Jan '11

19 Jan '11

[apologies for duplicates] Dear colleagues, We received some questions about the RIPE NCC's involvement in the World IPv6 Day that is planned for 8 June 2011. Please see some ideas and suggestions on RIPE Labs: http://labs.ripe.net/Members/mirjam/ripe-ncc-and-world-ipv6-day We are looking for feedback and suggestions, especially from subscribers of this working mailing list. Kind Regards, Mirjam Kuehne RIPE NCC

1 1

RIPE 61 - IPv6 WG minutes - draft
by Shane Kerr 18 Jan '11

18 Jan '11

Dear IPv6 working group, These are the draft minutes from the IPv6 working group session at the RIPE 61 meeting in Rome. Please send any comments/corrections within the next 4 weeks. Thanks! -- Shane, Marco, and David IPv6-wg chairs ------- Minutes from RIPE 61 Working Group: IPv6 Status: Draft Revision Number: 1 RIPE 61 IPv6 Working Group Rome, 16 November 2010, 16:00 – 18:00 Co-Chairs: David Kessens, Marco Hogewoning, Shane Kerr A: Administrative Matters The session started on time. Shane Kerr welcomed the attendees and mentioned that it was his first time as co-chair of the IPv6 Working Group, while also introducing his co-chairs David Kessens and Marco Hogewoning. Since there were quite a few items on the agenda and the session could be running late, he proposed to go ahead and start with the first presentation. There were no questions or comments from the audience. B. Experiences From an IPv6-only World Ari Keränen from Ericsson presented the work he conducted together with his colleague Jari Arkko about measurements in an IPv6-only environment, with IPv4 connectivity switched off completely. The presentation is available at: http://ripe61.ripe.net/presentations/140-ripe_rome_jari.pdf A speaker from the audience commented on the fact that their company had tried an IPv6-only setup on the server side and they encountered several issues, the biggest being DNS. Investigating the problem, it turned out that a certain percentage of the visitors could not resolve IPv6 addresses when that was the only option, therefore being unable to access the site even though the connection was fine. Ari found the problem interesting, and replied that whether on the client or the server side, it was important to enable communication between the old and the new Internet on all levels. Also, trying to force a specific technology on the users would not be feasible; having only Google and Facebook work for them may go unnoticed by half but would certainly make the others unhappy. Shank Kerr asked whether all the traffic for the experiment was directed through NAT64. Ari replied that there were only a handful of people involved, and they had used his particular home network as one part of the setup, which meant that not everything could be switched over since some devices did not support IPv6. Shane explained that the reason for his question was that since everything ended up translated to IPv4, it would be difficult to discern how much of the traffic was intended for the v4 or the v6 network. Ari answered that there are different configurations of NAT64, so v4 could be deployed only on the outside. A lot of their users were actually in this mode when accessing v4 destinations, however on the v6 Internet they could attain end-to-end IPv6 connectivity. It worked well for their purposes, but perhaps that had something to do with their years of experience running dual-stack configurations. Shane agreed and thanked Ari for his presentation. C. Detecting (and fixing!), IPv6 Dualstack Brokenness Tore Anderson from Redpill Linpro gave a presentation about his company's experience providing networking for customers and testing for broken IPv6 clients. The presentation is available at: http://ripe61.ripe.net/presentations/162-ripe61.pdf Shane Kerr commented he had been following their work for a few months and it was very cool. D. The Results on Introducing Native IPv6 at XS4ALL Marco Hogewoning introduced himself as one of the co-chairs of the Working Group, and then presented an experiment his company, XS4ALL, is conducting running native IPv6 on a residential DSL network. The presentation is available at: http://ripe61.ripe.net/presentations/128-MH-RIPE61-IPv6-XS4ALL.pdf Lorenzo Colitti from Google commented that the results were interesting, especially the fact that only ten percent of the users actually managed to get online using IPv6 -- probably the router firmware was to blame and an upgrade would have fixed it. However, the more important question, seeing as this was only a small-scale residential deployment, was how would this scale from 300 to 300,000 users -- since that is what the industry will have to do in the next couple of years. Marco answered that at a certain point they will probably feel confident enough to have it on by default for all customers, and that that would be the biggest hurdle. The major block that prevents them from doing that is currently the amount of CPE's with broken (non-IPv6-ready) firmware, and those have a lifespan of around two to three years. That would mean that in the next three years most of that installed base would be replaced, and if they were confident enough that it wouldn't break anything they would "push the button" and turn it on for all their 250,000 customers. Henk Uijterwaal from the RIPE NCC commented that he was actually one of the 300 users involved in the experiment, and he had the system working but then the rest of his family started to complain about things not working, like the telephone. The conclusion would be that not every combination of hardware, modems and phones would work. Marco replied that since the firmware they used on the modems in order to facilitate the experiment was new, it fixed some things -- like IPv6 functionality -- but broke others in the process, like the VoIP system used by the phone. He also added that there was a benefit there, when people at home that can't do much about fixing the technical problems will push their vendors to do it and they in turn will start taking IPv6 seriously. Lorenzo Colitti was interested to find out how long it took for the whole project to be implemented, from the design phase onwards. Marco answered that the design phase was completed in 2008. It took some time, mostly because they needed to test things properly. From a man-hour point of view it was pretty low, however they ran into issues with lawful requirements for interception under Dutch law -- they had to stall the project while waiting for the government systems to be fixed. Lorenzo rephrased the question to ask how long it would take if someone was in Marco's position and was asked by their manager to implement IPv6 on their network as soon as possible for all users. Marco answered that without checks and in a hurry it could be done in a week, but in order to do a proper job it could take anywhere from three to six months. Since more and more vendors are implementing IPv6 in their equipment, the problem remains having enough deployment to iron out all the bugs, since there is very little feedback on what breaks. When the deployment will reach a lot of people, it will be a lot harder for the vendor to ignore bugs and more pressure to fix things. Lorenzo concluded that it would then take around six months plus some time to make sure everything runs fine, and then asked if Marco's team was still pursuing this project. Marco said that indeed they keep working on it, the technical infrastructure and basics being taken care of, but things like reverse delegation, for example, needs to be fixed. They also have some services that are not yet deployed on IPv6, but mostly what they do now is wait for the vendors to come up with quality firmware -- the network side is pretty much done. There were no more questions or comments. E. RIPE NCC Stats Emile Aben from the RIPE NCC presented various statistics compiled using the data available to the NCC. The presentation is available at: http://ripe61.ripe.net/presentations/145-2010-11.ripe-61.ipv6-where-are-we.… Emile also demonstrated a new service offered by the RIPE NCC where anyone can compare the penetration of IPv6 in specific countries or regions: http://v6asns.ripe.net/v/6 Randy Bush inquired whether there were any privacy issues with the new service, since it included data about people visiting the website. Emile answered that since the IP addresses of visitors would not be published there should be no concerns, but legal advice will be sought regarding that just in case. Emile continued by presenting the current status of the "RIPEness" project and associated statistics. A member of the audience asked if suggestions for the fifth star were still being accepted. Emile replied yes, and the audience member said that his suggestion would be to call the helpdesk of the ISP and ask "I have an IPv6 question", and if the answer would be "Yes, how can I help you?", then the fifth star should be awarded. An audience speaker commented that this was the kind of material that decision makers like to look at, and asked if there was a disclaimer that this was easily measured external behaviour and of course being IPv6 ready, included lots of things that usually are not externally visible so that no new project will go along if it doesn't come with an explanation about how it would work with IPv6 or what the transition was. Emile answered that they didn't currently have such a disclaimer, but it was a good suggestion to put it on; however it would be hard to get the necessary data. Lorenzo Colitti from Google commented that the 2% figure of IPv6 penetration was ten times higher than the number Google had derived from their own measurement -- which was 0.2%. They had also measured 0.1% in the beginning of January, which coincided with the 100% growth seen on the RIPE NCC statistics. Therefore, he asked that a very big disclaimer be put on these results since it was the kind of thing decision makers look at, and the population visiting the ripe.net site was highly self-selecting and far more likely to have IPv6 than the average user. Emile agreed, mentioning that the ripe.net measurement was actually just one of several conducted, and the other sites had results closer to the Google number, far below 1%. Lorenzo expressed his concern that the people seeing higher numbers would become complacent while ignoring the far worse reality. Geoff Huston from APNIC commented that APNIC had been doing similar measurements, and their website presented the same bias towards technical visitors. Also, their services tended to be accessed by the same people repeatedly, so the measurement would have a very limited base. On the other hand, they had recently run the same measurement on a gaming site, which resulted in numbers that made the 0.2% seem extremely low. He then urged entities making measurements not to keep them closed, but open them towards the community, as biased or incomplete as they may be, since it is the only way to understand what is truly happening and the more data published, the better. He than shared the interesting fact that of the v6 visitors coming to their site, around 70% were running 6to4, so whether the technical community liked 6to4 or not it was very widely used and a simple routing addition like routing 2002/16 through a local relay would help those users. Another surprising discovery was the very low usage rates of Teredo, it's slow speed compared to the alternatives and the fact that it broke connectivity when installed locally. Shane Kerr intervened to announce that the discussion was running a little late and urged the participants to hurry up. A member of the audience commented that they had checked their RIPEness status and they did not have the fourth star because they were not advertising EU blocks since they had no EU customers. They were however advertising US blocks, which meant they had a fully working v6 network that was not counted properly, and there probably were quite a few others in the community in the same situation. Emile responded that the issue would be looked into. Tore Anderson from Redpill Linpro commented in response to Geoff Huston that their numbers were available on their website, all that was needed was for someone to take them and create a graphic or statistic. Talking about Teredo, he explained that it is only done by Windows by default, some CPE implementing it but only a few. Also, Windows Internet Connection Sharing does not share it out using RA's, which means only applications running on Windows will try and use Teredo. As a final note, newer versions of Windows implement RFC3484, which de-preferred Teredo, so that would be one reason for the very low Teredo traffic measured. Geoff Huston replied that the test they did targeted Teredo hosts by being IPv6 only -- even if it was de-preferred in dual-stack, if a resource would only advertise AAAA records then it would force IPv6 usage and that's why they saw some answers rather than none at all. Lorenzo Colitti added one final comment that when it came to numbers, it would be easy to publish statistics and graphs if that is what the community needs. He also expressed the fact that many in the industry are secretly hoping for 6to4 to go away, but the situation is not decided yet. There were no more questions or comments. F. Native IPv6 via xDSL – How to Tweak Your LNS The following presentation was by Fredy Künzler from Init Seven AG, with practical examples and technical details about implementing IPv6 on a xDSL infrastructure. The presentation is available here: http://ripe61.ripe.net/presentations/160-Native-IPv6-via-xdsl-how-to-tweak-… Martin Levy from Hurricane Electric asked what the response of the telecom provider was when they asked for v6 support. Fredy replied that they did not ask, since the telecom was not needed. Martin asked for confirmation that the provider's collaboration was not required for such a setup on DSL, and Fredy confirmed that it was completely transparent. Martin then continued by inquiring as to what the average telecom answer was when asking for v6. Fredy could not answer that question and requested members of the public to respond. A member of the audience commented that the usual response was that they mistake it for a question about TV and try to sell a TV bundle. Lorenzo Colitti asked the same question he posed to Marco earlier -- how would they scale the setup from the 12 current users to the total number of supported users. Fredy could not answer, explaining that was not their main focus in their business, and they did not have the high number of users as to have a scaling issue. Marco Hogewoning intervened to answer Martin's previous question. He said the response from their telecom provider was "Cool, let us know how it works so we can copy it off". Martin asked whether the telecom actually owned Marco's company, to which he replied affirmative. A member of the audience gave another response to Martin, keeping in mind that the situation was probably different in the European compared to the US market. He explained that the telecom provides the copper and a PPPoE service, which is then switched over L2TP to the ISP, so the layer 3 protocol is usually transparent; there were some bugs in equipment that prevented things from functioning correctly, but for the most part it was transparent for the telecom. Another member of the audience noted that there was an issue with BT in the UK and the previously mentioned bugs, which was still not corrected because officially they do not support IPv6. Because of that such a deployment would be difficult in the UK, at least with BT as the provider. A member of the audience commented that while he was a core network expert with expertise into the architectural aspects and less with the access network issues, he was quite positive there were large spots where actually transparent access was not available. There were no further questions or comments. G. Requirements for IPv6 in ICT Equipment Jan Žorž and Sander Steffann gave a presentation about their proposal for a formal document published by the RIPE community that would help governments and other institutions to select IPv6-capable devices and to devise tenders and auctions in a way that would ensure future equipment procured would be IPv6 capable. The presentation is available at: http://ripe61.ripe.net/presentations/307-Jan_Zorz-IPv6WG-requirements-in-IC… After Jan presented the proposal, he mentioned that there had been two consecutive versions of the draft and some response from the community. While items were added, the last call for discussion would end the following day, then the Chairs would decide if a new last-call was needed. He asked the audience if they thought the idea was useful and needed as a recommendation. David Kessens introduced himself as one of the co-chairs of the Working Group and noted that the current thinking of the IPv6 Co-Chairs was that the following day they would have more information from the comments gathered after the session and then they would be better able to make a decision. Jan thanked David and then asked Sander to present his own view on the issue. Sander commented that he had heard from a lot of organisations wanting to deploy v6 but lacking the experience in the field that such a proposal would be appreciated. The recommendation was clear in what a device should support, by making it a requirement for v6 to perform on par with v4, while also including a section about the knowledge and skills necessary of the integrator. As such, it would constitute a good document to standardise v6 requests around. Constanze Bürger from the German Ministry of the Interior commented in support of the proposal that from a Government point of view it was much appreciated and welcome since the vendors do not provide the necessary information, while Governments themselves do not know what to ask for. She also proposed improvements to the requirements, by going into more details than the RFC level, like a matrix that would match legal requirements and policies in the EU. David Kessens intervened to ask for brevity since the time was already short, and proposed that further discussion regarding improvements should be continued on the mailing list or in person after the session ended. Constanze reiterated their support and the necessity of the proposal. Sander thanked her for the support and the input received and mentioned that he would like to see the proposal go through the process as quickly as possible, and perhaps implement further changes in a second version, since this was an open, ongoing process. There were no further questions or comments. This proposal is now a published RIPE Document: http://www.ripe.net/ripe/docs/ripe-501.html H. Update on Policy Proposal 2010-06 For the last presentation in the session, Marco Hogewoning returned to the stage together with Remco van Mook to present a policy proposal currently in the draft stage. The presentation is available at: http://ripe61.ripe.net/presentations/309-MH-RIPE61-2010-006.pdf After giving the presentation, Marco explained that since he was one of the proposers, he would not do any Chair processing in this case, leaving it to David and Shane to make all the decisions. Wilfried Woeber from ACOnet/Vienna University asked if there was any reason for doing the same statistics that were done on IPv4 with IPv6 (like percentage of the usage of a block of addresses compared to the number of consumers or end points). He expressed the opinion that something like that would not be needed with IPv6 since there would be no real shortage. Marco answered that at a certain point HD ratios need to be calculated, but it's more a matter of implementation. Since in the v4 case the statistics were not part of the policy and just a means of showing the usage of addresses, it was a good idea to copy that over to v6. Of course, if the consensus would be that there was no such need it could be amended. Wilfried explained that he was referring to the dynamic component of DSL addresses and other surrounding issues, while admitting he had not studied the policy in detail. Marco said that on the v4 version it was specifically stated "broadband user", and that implied 24/7 usage since a provider could not assign 2,000 addresses with only 500 customers unless making another assignment. While such a policy was reasonable with IPv4, it would still work with IPv6, since a procedure was needed to have someone who was running out of a /32 be able to justify another one instead of simply asking for a /28 -- otherwise everyone could simply be assigned a /28 from the beginning. Wilfried commented that at the time he was working on an address plan for a large customer, and it looked like they would not use the same size for all end points but instead define three sized groups. He would have liked to see a mechanism to document such issues within the framework of the proposal. Marco answered that the proposal text was only finished in that afternoon and it should be coming out, they were just waiting for the RIPE NCC to conduct an impact analysis. Afterwards it would be pushed to the mailing list. In the proposed version, it stated that one can nest objects but only up to one level -- that was to prevent people from going into the /128 level while allowing for instance a number of /48's to be grouped and another separate /48 to be split up in /64's. David Kessens reiterated that Marco would not be involved in the discussions and decisions regarding this proposal, and that the current status was waiting for the RIPE NCC to conduct an impact analysis and then the document should be published, since it was already discussed quite a bit and it did not stir too many controversies. There would be a two-week review phase and another last call after that before the process will be finalised. Marco remarked that they would involve multiple Working Groups and their Chairs in the discussion, the Database WG and Address Policy WG since it concerned them as well. There were no other questions or comments. As the presentations ended at 18:05, Shane Kerr thanked everyone present and asked for an open mike session. He also reminded the attendees that the session was already overtime. Marco Hogewoning reminded the attendees of the mailing list for the IPv6 Working Group: http://www.ripe.net/mailman/listinfo/ipv6-wg The address to contact the Working Group Co-Chairs: ipv6-wg-chairs(a)ripe.net Randy Bush commented that for the ones that have been around Internet technology for a while to notice the progress, things have really changed in the past few months, and even though we may not see 80% deployment of IPv6 it is on people's minds and the next months should be very interesting. He also praised Marco for his presentation. Shane Kerr officially ended the session at 18:09 by wishing everyone a good night.

2 1