- ipv6-wg - mailman.ripe.net

ipv6 multicast
by Kristoff Bonne 01 Apr '10

01 Apr '10

Hi, As multicast is part of standard ipv6-stack, I was wondering how many ISPs who have ipv6 enabled have (or plan to have) ipv6 enabled on their backbone. Are there any statistics on this? Cheerio! Kr. Bonne.

1 0

IPv6 Pilot in NL: seeking customers
by Marco Hogewoning 30 Mar '10

30 Mar '10

(wearing my XS4ALL hat) We just announced to the media we are expanding our current trials to support native IPv6 over DSL to 1000 lines. These 1000 places are given away on a first come first serve basis. To give everybody a fair chance people can subscribe to this pilot starting Friday April 2nd, 12:00 CEST. In this pilot we ask for people to supply their own DSL cpe which is IPv6 capable or even hack around with linux images where possible. This pilot will serve 3 main goals: - Test interoperability between our gear and setup and the solitions currently on the market - Test those CPE solutions in the wild, we tested some of them in our own lab but it's hardly the same as everyday use in a random residential environement. - Fine tune our support procedures and figure out what training is needed. Next to that We'd love to see what problems will arise when IPv6 is switched on in a regular residential networking environment. Now obviously, since this is a DSL pilot there are some geographical boundaries on who can enter. If you happen to live in the Netherlands and are an XS4ALL customer please do subscribe. We already posted a list with some of the CPE we have tested and are known to work, these include some AVM FRITZ!Box models, some cisco SOHO boxes (8xx serie) and the latest release of Draytek Vigor. If you happen to know some others or happen to built DSL modems yourself, please contact me of list. Basic requirements are ADSL2+ with PPPoA, IPCP and IPv6CP using DHCPv6-PD to get the addresses. As a first result, the press release was picked up by a lot of media and the comments are mostly positive. Hopefully in a few weeks time we have some more data to report on. The original annoucement (in Dutch): http://www.xs4all.nl/klant/ipv6/ MarcoH

1 0

Internet Society IPv6 Workshop
by Phil Roberts 30 Mar '10

30 Mar '10

The Internet Society is hosting an IPv6 Deployment Day on April 22 in Seattle, Washington. The meeting is intended for operators who have deployed, are deploying, or are planning to deploy IPv6 in their networks. The proposed topics include business related issues for IPv6 deployment, discussion of pitfalls in IPv6 deployment, and specific technical issues due to IPv6 deployment that potentially affect the whole Internet. This is an open meeting and all are welcome, but space is limited so you will need to register: https://www.isoc.org/isoc/conferences/registration/?id=7ce20e4c88b7e328. If you have any questions please feel free to contact me, Phil Roberts (roberts(a)isoc.org) or Mat Ford (ford(a)isoc.org)

1 0

Spam sent over IPv6 - See results on RIPE Labs
by Mirjam Kuehne 30 Mar '10

30 Mar '10

[apologies for duplicates] Dear colleagues, We were curious to see how much spam is sent over IPv6 these days. Find the results on RIPE Labs: http://labs.ripe.net/content/spam-over-ipv6 We will continue to measure this. If you have any comments or suggestions, please let us know. Kind Regards, Mirjam Kühne

1 0

Measuring IPv6 at Web Clients and Caching Resolvers
by Mirjam Kuehne 25 Mar '10

25 Mar '10

[apologies for duplicates] Dear colleagues, As the remaining IPv4 space continues to shrink, it’s important to keep an eye on how the IPv6 Internet develops. We prototyped a method to measure the IPv6 capabilities of caching DNS resolvers that end-users use when browsing the web. The results of these measurements are now published on RIPE Labs: 1. A summary of the measurements and results can be found here: http://labs.ripe.net/content/measuring-ipv6-web-clients-and-caching-resolve… 2. Some more detailed analysis (including a breakdown of IPv6 usage per country and city) are here: http://labs.ripe.net/content/measuring-ipv6-web-clients-and-caching-resolve… 3. The methodology we use for these measurements are described here: http://labs.ripe.net/content/measuring-ipv6-web-clients-and-caching-resolve… All articles can be accessed from the RIPE Labs home page at http://labs.ripe.net If you have any comments or suggestions, please do not hesitate to submit them to the RIPE Labs forum or send them directly to me. Kind Regards, Mirjam Kuehne RIPE NCC

1 0

Call for agenda items for RIPE in Prague
by Shane Kerr 19 Mar '10

19 Mar '10

Hello all, The next RIPE meeting in Prague is coming up. We would like your input on the agenda for the meeting. We are hoping to have a brainstorming session at the beginning of the IPv6 working group, to try to come up with some ideas about how we can achieve the goals in our new charter. We would also like other items. Our intention is to look at each topic and try to get ones of interest to the larger RIPE community in the EOF portion of the meeting, and have the IPv6 working group focus on things interesting to people working in the IPv6 world. All items that are IPv6-related are of interest. Please send your proposals to David, Marco, or myself - all reasonable offers considered. Your friendly co-chair, -- Shane

1 0

IANA depletion in less than 1 year?
by Shane Kerr 17 Mar '10

17 Mar '10

Hey all, I noticed this site in someone's signature: http://ipv4depletion.com/ It uses a different prediction than the well-known one by Geoff Huston, although the results are not too different (which I guess is good): http://ipv4depletion.com/?page_id=4 Interesting. :) -- Shane

5 4

Re: Expected time frame for IPv6 deployment
by Edu Abume 14 Mar '10

14 Mar '10

________________________________ From: Edu Abume <eduabume(a)yahoo.com> To: ipv6-wg(a)ripe.net Sent: Sat, March 13, 2010 1:24:35 PM Subject: Expected time frame for IPv6 deployment Hi Does anyone know the average period for IPv6 deployment. What is the estimate for small and large sized organization? Are the transition mechanisms the same for these organizations? Thanks and awaiting reply. Edu

4 3

Expected time frame for IPv6 deployment
by Edu Abume 13 Mar '10

13 Mar '10

Hi Does anyone know the average period for IPv6 deployment. What is the estimate for small and large sized organization? Are the transition mechanisms the same for these organizations? Thanks and awaiting reply. Edu

1 0

IPv6 allocations for 6RD
by Jan Boogman 11 Mar '10

11 Mar '10

Hi, we are planning to offer IPv6 connectivity to our xDSL and FTTH customer base via IPv6-6RD. (see <http://tools.ietf.org/html/draft-townsley-ipv6-6rd-01> or for a working implementation Free's presentation at RIPE-58: <http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/ipv6-free.p…>). We asked RIPE NCC for a larger than /32 allocation (because of the way how 6RD encapsulates the customers IPv4 address in his IPv6 address and also because we want to give the customer a small subnet). The IPRA now isn't sure how to proceed and after consultation with the Policy Development Manager asked me to pose the question to the community at large. What do you think, should RIPE NCC allocate larger than /32 blocks to LIRs for cases like this and not only based on the number of end-customers? Cheers Jan Swisscom IP-Plus - AS3303

12 27

fyi: dutch special issue coming up.
by Peter van Eijk 11 Mar '10

11 Mar '10

Hi everybody, For those of you who read Dutch and are not a member of the dutch IPv6 taskforce list, I have just posted an announcement for the special issue of a dutch IT management magazine on ipv6-tf(a)ams-ix.net Regards Peter van Eijk, +31 6 2268 4939, peter @ digitalinfrastructures.nl

1 0

/127 for point to point links
by Vegard Svanberg 25 Feb '10

25 Feb '10

Hello. We've stumbled across a problem with a router manufacturer, which won't implement support for /127 prefix lengths. Now, we do have peering/transit partners using /127 on their p2p links. The result is that we either cannot peer with them, or will have to get new routers. RFC 3627 states that /127 is considered harmful, however I do feel this RFC confuse people since it doesn't propose a definite solution. It suggests a number of solutions and indicates using /64 is the right thing. I must say I strongly disagree on that conclusion. Wasting so much address space on point to point links just makes no sense to me. So I'm not sure what to do here. I have to convince someone; either our partners or the router manufacturer. I have the impression that /127 is used widely out there. -- Vegard Svanberg <vegard(a)svanberg.no> [*Takapa@IRC (EFnet)]

14 16

Confirmation of Marco Hogewoning and Shane Kerr as co-chairs
by David Kessens 22 Feb '10

22 Feb '10

All, Our last call to confirm: Shane Kerr http://www.ripe.net/ripe/maillists/archives/ipv6-wg/2010/msg00038.html and Marco Hogewoning http://www.ripe.net/ripe/maillists/archives/ipv6-wg/2010/msg00041.html as additional co-chairs for the ipv6 working group has ended. I have not received a single objection. I did receive a large number of positive responses before and after the Last Call started. If you like, all responses were posted to the mailing list and can be viewed by checking the working group mailing list archives. I believe we have now reached consensus to appoint Marco Hogewoning and Shane Kerr as co-chairs for the ipv6 working group. I would like to thank everybody for your participation in the discussion and I would like to welcome Shane and Marco as my co-chairs. Thanks! David Kessens ---

3 2

Re: [ipv6-wg] Publication of default assignment sizes for end-user network ?
by Denis Walker 17 Feb '10

17 Feb '10

>>> Now this does not forbid you to register individual >>> assignments into the public database, but doing so poses >>> various problems. Not only the sheer number of assignments >>> can be a problem, but also keeping that registration >>> up-to-date will have serious impact on your day to day >>> operations and especially with residential users there might >>> be privacy issues as well. >> >> If we would have a distributed database protocol to extend the >> RIPE database into the LIRs, then this would not be an issue. >> I'm thinking of something like DNS. >> >> For instance, if I need to look up data on three >> /48s in fdb8:e914::/32 I would first send a lookup request to >> RIPE. The RIPE db would tell me that all data for >> fdb8:e914::/32 is in a server at fdb8:e914::dbdb. I would >> cache that information, and send my first lookup request to >> the distributed server. After getting my reply, I would prepare >> to send the second request for fdb8:e914:c20f::/48, notice that >> the /32 is already in my cache, and use the cached server >> instead. >> >> This is roughly the way DNS lookups work with the result that >> the detailed data does not have to be kept in one central >> location. I would like to see the RIPE db move in the same >> direction. >> >> At the same time, I would like to see the spec opened up a bit >> so that the distributed server operators would be free to add >> additional attributes to existing objects, and additional objects >> so that there is the possibility of using the same distributed >> lookup mechanism for geographic or language identifications as >> well. > > This may as well be another solution, but it still needs some way of > signalling where the actual boundary between customers is as I see > no way to delegate it down to the customer level unless there is > some way to incoorperate it into the CPE. > > And that's I think my main argument opposing to this path, it takes a > lot of time to and develop that model ad get it implemented across > all the LIR's. The big benefit of solving it at the RIR level is that it's > only a handfull of systems that need to be changed and the basic way > to retrieve that information is already there in the form of the whois > protocol. > > I'm not syaing I don't like your solution, I'm just afraid that > deployment will be just to late. > > Grtx, > > Marco Hi Marco Sorry for the late response. I missed the original posting on this list, then saw your follow up on the IETF list. The RIPE NCC also has the same problem with the RIPE DB. Currently we implement some rate limiting on individual IP addresses. As you have explained here, this does not scale for IPv6. The Database Group at the RIPE NCC has already done a lot of thinking internally on this and other issues on moving the RIPE Database into an IPv6 world. We would welcome ideas and thoughts from the community about use cases, issues and problems you can foresee with the RIPE DB in an IPv6 world, even if people don't have the solutions. Of course suggested solutions are also welcome. Let me throw some pointers at you from our thinking. Firstly don't let your thoughts be constrained by the current RIPE DB. This was designed in an IPv4 world with IPv6 bolted on later. Think out of the box. Don't worry too much about the data model, interfaces, APIs, tools we have now. Focus on what the RIPE DB needs to do for you in an IPv6 world. For example you discuss the problem of not knowing what the block size is that any IPv6 address belongs to. This is because the current thinking is to not store all assignments in the RIPE DB. Suppose we re-assess what data needs to be stored, who needs access to it and for what purpose. Suppose we design a new data model and provide new APIs and new tools built on those APIs. Then one possibility may be for each LIR to upload a daily dump of assignment changes and leave it up to the RIPE NCC to process the data. We can do batch processing over night and sync the RIPE DB with LIR's databases. This will not have the serious impact you referred to on your day to day operations. We don't need to store the same information we do now for an IP address. We can store different information about addresses used for different purposes. Maybe not all the stored information needs to be accessible by all people who query the RIPE DB. So we can build in data protection safeguards. With new query interfaces, we can provide access to this data more easily and in many different formats. So perhaps you can widen your thinking now about possible solutions to new problems in an IPv6 world. Regards Denis Walker Business Analyst RIPE NCC Database Group

1 0

Announcement: RIPE NCC Training Courses
by Olivia Mijnals-Ruimwijk 16 Feb '10

16 Feb '10

[Apologies for duplicate e-mails] Dear Colleagues, The RIPE NCC invites you to register for one of our upcoming training courses: - The LIR Training Course This course teaches LIRs how to request Internet number resources and interact with the RIPE NCC. A course outline is available at: http://www.ripe.net/training/lir/outline.html - The Routing Registry Training Course This course teaches LIRs how to use the RIPE Database for routing. A course outline is available at: http://www.ripe.net/training/rr/outline.html - The IPv6 Training Course This course teaches LIRs about the need for IPv6 and includes basic information on how to plan your deployment. A course outline is available at: http://www.ripe.net/training/ipv6/outline.html To see the location of upcoming courses and to register, please use the LIR Portal or complete the registration form on our website at: RIPE NCC Upcoming Courses List & Registration https://lirportal.ripe.net/lirportal/training/course-list.html If you have any questions, please do not hesitate to contact us at <training(a)ripe.net>. Kind regards, Rumy Kanis Training Services Manager RIPE NCC

1 0

Discussion period for co-chair selection until 20100208
by David Kessens 12 Feb '10

12 Feb '10

All, The call for candidates for co-chairs of the IPv6 working group has resulted in two candidates. See below for their names and a link to the mailing list with their motivations and plans for the working group: Shane Kerr http://www.ripe.net/ripe/maillists/archives/ipv6-wg/2010/msg00038.html Marco Hogewoning http://www.ripe.net/ripe/maillists/archives/ipv6-wg/2010/msg00041.html This brings us to the next step in our process: 1) The nominees are given a chance to determine whether they want to be considered or withdraw as they decided that there are other good candidates already available 2) The community may express opinions that could help the candidates to come to a decision on whether they want to be continued to be considered as a candidate - the community may consider appointing more than one co-chair in case of several good candidates Let's take until the end of Mon Feb 8, 2010 in a timezone of your choice to determine an outcome for both 1) and 2). I already have seen some discussion regarding point 2) and it leads me to believe that there is at least some support to appoint both candidates as co-chairs. Before making such a determination though, I would like to see a bit more discussion/comments, especially from people who have not taken a position yet on this topic. Basically, knowing our candidates, I would like to hear from you whether you prefer to appoint one or two co-chairs, and whether you have any preference for either candidate in case you believe one co-chair is enough. Note that this period is for open discussion and that it is perfectly fine to do alternate proposals. Our objective is to see if we can come to a consensus which allows us to avoid more complex ways of making a selection such as a vote. After our discussion period is over, I will determine if there is enough basis to do a Last Call to confirm a selection decision as determined from our discussion phase, or whether we perhaps need a bit more time for discussion or that we will have to resort to organizing a vote. I hope this helps, David Kessens ---

10 12

Re: [ipv6-wg] Youtube over IPv6!
by Peter van Eijk 12 Feb '10

12 Feb '10

A couple of days ago Martin Milnert wrote <qoute> The time when it began is clearly visible in our own IPv6 graphs, http://stats.csbnet.se/public/ipv6/csbnet-ipv6-traffictypes.html , and you can see similar correlated data at for example http://www.de-cix.net/content/network.html . </quote> What puzzles me is that we see none of this at the AMS-IX, have a look at http://www.ams-ix.net/sflow-stats/ipv6/ Does anybody have a clue as to why that is? Peter van Eijk (dutch IPv6 taskforce)

6 9

Re: [ipv6-wg] Youtube over IPv6!
by Mirjam Kuehne 12 Feb '10

12 Feb '10

Dear all, Martin Millnert wrote: > > There are plenty previous work done in following/measuring several of > > these points. Would be nice with some potaroo.net type, stable, place to > > follow it, though. > I am not sure this is exactly what you were looking for: On RIPE Labs we published a list of IPv6 measurements various people are doing: http://labs.ripe.net/content/ipv6-measurements-compilation It also lists to potaroo, RIS, CAIDA and a lot more. We are currently working on a follow-up article listing data and statistics we found in the meantime. If you are aware of other measurements related to IPv6, we'd be happy to include them. Kind Regards, Mirjam Kühne RIPE NCC

1 0

Re: [ipv6-wg] /127 for point to point links
by Vegard Svanberg 12 Feb '10

12 Feb '10

* Chris Buckridge <chrisb(a)ripe.net> [2010-02-12 11:36]: > Thanks for your email. I would suggest that you send your question > to the RIPE IPv6 Working Group mailing list - you can subscribe > here: Uh, I did, didn't I? -- Vegard Svanberg <vegard(a)svanberg.no> [*Takapa@IRC (EFnet)]

1 0

IPv6 Act Now: News Update
by Chris Buckridge 11 Feb '10

11 Feb '10

Hi all, A couple of news items from the IPv6 Act Now newsfeed over the last week that might be of interest: First accreditation issued for testing to US IPv6 product specs (9 Feb 2010) Amid all the discussion of government leading the way on IPv6 through procurement, news from the US that the University of New Hampshire's test lab is among the first wave of labs to be accredited to test networking products for compliance with government IPv6 specifications. <http://www.ipv6actnow.org/2010/02/ipv6-and-its-future-prospect-in-developin… > AfriNIC embraces Internet challenges in Africa (8 Feb 2010) An extensive interview with AfriNIC CEO Adiel Akplogan, discussing the challenges facing the region's Internet community and some of the new roles AfriNIC is taking on, including working with law enforcement agencies and participating in the Africa Union heads of state summit. <http://www.ipv6actnow.org/2010/02/afrinic-embraces-internet-challenges-in-a… > Pakistan needs to shift to Internet Protocol Version 6 (9 Feb 2010) IPv6 makes it into the Pakistani press, with the IPv6 Monitory Group of Pakistan Telecommunication Authority (PTA) making a number of recommendations for the widespread adoption of IPv6 in the country (including establishing a National Internet Registry). <http://www.ipv6actnow.org/2010/02/pakistan-needs-to-shift-to-internet-proto… > Regards, Chris Buckridge, RIPE NCC

1 0

Request for approval of the minutes for wg session RIPE 59 (20100207)
by David Kessens 10 Feb '10

10 Feb '10

Please find below the minutes from the IPv6 WG session at RIPE 59. The minutes will be declared final if no objections, except for minor editorial corrections that will be fixed before publication, will be received by the end of Sunday February 7, 2010 in a timezone of your choice. Finally, I would like to thank Alex Band for the excellent minutes! Thanks, David Kessens --- RIPE Meeting: 59 Working Group: IPv6 Chair: David Kessens Date: Tuesday October 6, 2009, 16:00-18:00 David welcomed the attendees and opened the session. A. Administrative Matters o Welcome o Select scribe: Alex Band o Select Jabber Monitor: Rumy Kanis o Finalize agenda o Approval of minutes from previous working group meeting B. RIPE NCC IPv6 Update James Aldridge, RIPE NCC http://www.ripe.net/ripe/meetings/ripe-59/presentations/aldridge-ncc-update… There were no questions. C. Future of the Working Group: Charter Discussion Shane Kerr, David Kessens. Input from the audience http://www.ripe.net/ripe/meetings/ripe-59/presentations/kessens-v6-wg-futur… Shane mentioned that the initial idea for an IPv6 Working Group came from looking at the statistics Geoff Huston publishes. "Make IPv6 Happen", was the summary of the charter of the WG. Most of the discussion on IPv6 is actually in the Address Policy WG, so he proposed to shut down the WG and move on to a bigger and better thing. David asked the audience for input. Olaf Kolkman (NLNetlabs) asked how the activities of the WG tied into the IPv6ActNow website. Shane said that there is not really any tie in, and that he thought that is was a shame that something like IPv6ActNow is necessary at all. Rob Blokzijl (RIPE Chair) mentioned that the message that is coming out of the WG is heard by the community at large, however, it doesn't seem to be received and digested by the industry on a wide scale. He proposed that the WG is not shut down, because there is important work to be done, especially in the coming two years and when IPv4 has run out. Gert Doering (Spacenet) commented that the WG is not the place where people go nowadays to learn about IPv6. At the RIPE Meeting, those kinds of discussions are held in the Plenary. Rob gave an example: there were two presentations about the general implementations of IPv6 at customer premises. In one case, the CPE worked fine, in the other it didn't. He would have liked to have seen a technical presentation in the IPv6 WG session on why that is. Shane responded there are definitely opportunities for the WG in that capacity, and even other topics related to IPv6, like Multi-layer NAT. Denesh Babutha (Aexiomus//Cyberstrider) agreed that the WG had reached the end of its useful life as originally envisaged. He said that, as such, the WG needs to evolve, and he thought that this needed to happen through the the charter. Denesh added that the WG needed to move away from repeating the IPv6 situation in every single meeting and move onto more useful discussions. The new charter should be inclusive of other industry areas too. David said that there were many topics covered by the WG that were not originally in the charter. Bernard Tuy said that there is an enormous need for technical training and that kind of knowledge can come from the WG. David asked the audience how to move forward with the WG and whether it should continue in it's current form? Ruediger Volk (Deutsche Telekom) commented that the current form seems to be "quasi-plenary". Rob commented that the WG should be modest in its aims and not try to reach the end goal without some intermediate steps. He said that the WG should focus on real world implementations. Shane commented that the WG did not need to come up with a new charter here and now. Rob proposed that a new draft charter is written. David summarized the feedback for a new charter as more focus on education and outreach activities. Maarten Botterman said that not all of those activities have to be within the WG. David asked the audience if preparing for a hybrid IPv4/IPv6 world should be part of the charter. Rob commented that outreach should lie with the RIPE NCC efforts, such as the IPv6ActNow initiative. He said that training is a sensitive issue because the RIPE NCC does not want to compete with its members. Rumy Kanis (RIPE NCC Training Services Manager) commented that the RIPE NCC offers IPv6 training, but careful steps were taken to ensure the RIPE NCC does not compete with the membership. Marco Wertejuk (Binconsult) said that he believes the focus for the new charter should be "how to encourage conservation of IPv4 and deployment of IPv6". David said that he assessed from the audience feedback that there isn't much support for the WG to focus on non-technical outreach activities. David asked Rob for a time line. Rob said that the WG should take things slowly, and propose a new charter at the next RIPE Meeting and that further discussions should continue on the mailing list. D. Future RIPE Network Experiments - David Kessens. Input from the audience David asked the audience if there was further interest in IPv6 network experiments during a RIPE Meeting. Gert said that forcing IPv6 on people is actually a good idea. He said we should even go as far as making the RIPE Meeting network IPv6 only for the whole week. He added that we should do the experiment without NAT-PT. David said that he would like to see a completely new experiment. Marco Hogewoning (XS4all) said that although IPv6 connectivity in general is good, tunneling is needed in some places in order to get full connectivity. David Wilson (HEAnet) said that the IPv6 hour should be repeated, and that the WG should get new experiences because things have changed since the last time it was done. Izumi from JPNIC that for their experiments, they created different testbeds for different kinds of implementations. David asked the audience if the IPv6 Hour should be rerun at future meetings.. There is consensus that it should be. E. IPv6 Deployment: What are the Remaining Issues and Bottlenecks? - A panel discussion with interactive input from the audience. Moderator: Maarten Botterman, GNKS Consult http://www.ripe.net/ripe/meetings/ripe-59/presentations/botterman-towards-v… Gert Doering introduced himself and asked the question "What kind of Internet do we want to have in five years?". Geoff Huston introduced himself and in a slide set proposed the question "Is the IPv6 transition an example of market failure?" http://www.ripe.net/ripe/meetings/ripe-59/presentations/huston-ipv6-transit… Kurtis Lindqvist introduced himself and explained his own experiences with IPv6 deployment. He said that doing a slow and gradual implementation has been very beneficial. Maarten Botterman did a live survey, with the question "What would you gain by postponing, and what would you gain by stepping up to the plate, earlier rather than later?". 40 votes were cast, most go to: o By stepping up to the plate I have time and space to do the transition, which will allow me to do it gradually and well thought through o By stepping up to the plate I confirm my brand's image as 'state-of-the-art' or 'top-of-the-wave' Geoff commented that the respondents are most likely non-representative. Gert said that he is not surprised with the numbers. Kurtis said that looking at the responses, he is optimistic. Maarten said that some people responded with 'none of the above'. He asked three of those people to comment: Ruediger said that for all of the relevant players there is still enough time for doing a proper job. Bernard said that there was no vendor support, so ISPs will never start until that happens. Jan Hugo Prins said that there will never be end user demand. Deployment is not picking up because of security issues. Geoff reiterated that he thought that the situation we are finding ourselves in right now is no accident. It is in many companies' interests to delay IPv6 adoption. Shane agreed with Geoff. Gabriella Paolini (GARR) said that the biggest issue is that middleware doesn't support IPv6 and that changes very slowly. Maarten did another live survey with the following question: "There is perception and experience of/with a number of hurdles that seem to be difficult to overcome. Which are important to you?". o As there is very little customer demand, I cannot justify the investment to my management, even if I would like to move o I have the experience that my vendors cannot deliver what I need o None of the above (highest score) Ruediger said that the options are very extreme. Slow and gradual deployment is a real option. Geoff commented that in his days at a telco, the biggest cost turned out to be customer support. IPv6 could become expensive in that respect with end users calling in because of issues. Maarten asked people to comment: - Wilfried Woeber (Vienna University) commented that he would have to select 'none of the above' for all questions. His issue is that the questions are too black or white. The biggest problem from his point of view is in layer 7 or 8: infrastructure, applications etc. The backbone has been done for years. - Marco said that he agreed with Geoff, the cost is not in the hardware. IPv6 is not a product, don't pay extra for it. - An attendee said that in a lot of cases, even though the product spec sheet says that IPv6 is supported, there is no feature parity with IPv4. Gert said he agreed with most of the comments. Geoff said that any vendor is willing to give you what you want, as long as you put down the money. Kurtis added that there was also a big push from vendors for MPLS. Marco added that some IPv6 functionality used to be free, but after vendors realized that there was a market for it, they started charging for a license. Maarten did another live survey, the results with the most votes were: o The deployment of IPv6 is unavoidable for my organization in due time o Technically, everything is in place to deploy IPv6 Geoff commented that openness is the key in the end. IPv6 is the only way to guarantee that. Kurtis added that he was surprised that so many people responded "I will deploy in due time", because that is pretty close. Geoff re-stated that the market is well informed, and that this situation is intentional in order to maximize shareholder profits at large corporations. Ruediger agreed that the industry is flooded with information. But he asked how enlightened are people? Geoff responded that it's all about vendor lock in. Brian Nisbet (HEAnet) said that the WG keeps having the same discussion meeting after meeting. He said that he could not believe that people are not well informed. Kurtis said that CFO's cannot be convinced of the urgency of something that will happen two years from now. An attendee said that for mobile operators, the vendors of mobile terminals are the blockers. Maarten showed the results of the last survey. The panel shared some closing thoughts. The general thought was that the community should stop distributing messaging, and start moving packets. Maarten closed the discussion. F. Developments/Initiatives Regarding IPv6 in the RIPE Region and Beyond - Input from the audience No input was given. Y. Input for the RIPE NCC Activity Plan - Input from the audience No input was given. Z. AOB None. David closed the session. ---------

2 5

Last Call: Confirmation of co-chairs (20100217)
by David Kessens 10 Feb '10

10 Feb '10

The discussion phase regarding new co-chair positions has now ended. It seems that there is strong support to appoint: Shane Kerr http://www.ripe.net/ripe/maillists/archives/ipv6-wg/2010/msg00038.html Marco Hogewoning http://www.ripe.net/ripe/maillists/archives/ipv6-wg/2010/msg00041.html as additional co-chairs for the ipv6 working group. Please let us know if you have objections to such a solution by the end of Wed Feb 17, 2010 in a time zone of your choice. There is no need to restate your supportive position again as there was already a significant number of people that expressed support for this approach. Thanks, David Kessens ---

1 0

announcing DNS64-NAT64 opensource implementations
by Marc Blanchet 08 Feb '10

08 Feb '10

<sorry for cross-posting/> This is to announce the availability of two NAT64-DNS64 open-source implementations by Viagenie, as follows: ====== NAT64 ====== BSD PF: this implementation of NAT64 is made by modifying the PF packet filter available on BSD systems. A new 'nat64' statement is created in the pf.conf file to enable the nat64 functionality. Linux Netfilter: The implementation of NAT64 for linux is available as a kernel module. It uses Netfilter's facilities for packet interception. The configuration is done with parameters provided at module insertion. ====== DNS64 ====== As announced in july 2009 during IETF Stockholm, the companion DNS64 functionality is also available in two implementations, as follows: BIND: this implementation of DNS64 is made by modifying the BIND DNS server. A new "dns64-prefix" statement in options is created in the named.conf file to enable DNS64 functionality. Unbound: this implementation of DNS64 is made by adding a module to the Unbound DNS server. To enable the DNS64 functionality, the module should be declared and the dns64-prefix statement should be added in the unbound.conf file. The two functionalities (NAT64 and DNS64) make a complete system for translating IPv6-IPv4 packets. The source code, some pre-compiled packages and project description are available at: http://ecdysis.viagenie.ca. This project was funded by NLNet foundation and Viagenie. We are looking for feedback, patches, suggestions from the community. http://ecdysis.viagenie.ca Regards, Marc Blanchet, Simon Perreault, Jean-Philippe Dionne Viagenie

1 0

IPv6 experiments at future RIPE Meetings
by James Aldridge 08 Feb '10

08 Feb '10

Reading the minutes of the IPv6 WG at RIPE 59 I read: > David asked the audience if the IPv6 Hour should be rerun at future > meetings.. There is consensus that it should be. Rob Blokzijl has asked that we treat the RIPE Meeting network as a production network. This effectively means that we won't be turning off the dual-stack network for another "IPv6 Hour". What we can do is to build the IPv6 only networks as we did in Berlin and make these available to anyone who wants to use them, but without the complications caused by the IPv6 Hour. One question that remains is whether, with rfc2766 now "historic", providing NAT-PT on the IPv6-only networks is worthwhile for RIPE 60 and future meetings. Would it be enough just to provide the IPv6 networks but without any translation to be able to reach the IPv4 legacy Internet? Any feedback would be appreciated. Regards, James -- James Aldridge, Senior Systems & Network Engineer, RIPE NCC RIPE Meeting technical team

17 24

Re: [ipv6-wg] Discussion period for co-chair selection until 20100208
by Ralph Smit 08 Feb '10

08 Feb '10

Marco Hogewoning wrote: > On 3 feb 2010, at 23:44, David Kessens wrote: > >> Basically, knowing our candidates, I would like to hear from you >> whether you prefer to appoint one or two co-chairs, and whether you >> have any preference for either candidate in case you believe one >> co-chair is enough. > > > Hi All, > > I had a short chat with Shane this afternoon and we would like you to > know we as candidated would prefer the option to appoint two co-chairs. > Shane and I have known eachother for quite some time and our goals and > objectives for the future of the IPv6 working group are the same, we > both are looking forward working with David and the community to live up > to the new charter en make IPv6 a succes. > > Thanks for all the support so far, > > MarcoH and Shane > > > I support both candidates and agree with many who replied before me (and the candidates themselves) that 2 co-chairs would be a good idea. Regards, Ralph Smit.

2 1