RIPE 61

Minutes from RIPE 61
Working Group: IPv6
Status: Final
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.pdf

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-your-LNS_v0.3.pdf

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-ICT.pdf

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

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/ripe/mail/wg-lists/ipv6-working-group

The address to contact the Working Group Co-Chairs: ipv6-wg-chairs@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.