RIPE 68

WG Chairs: Shane Kerr, Marco Hogewoning

Session I: 15 May 2014, 9:00- 10:30

Scribe: Mirjam Kuehne

A. Welcome and Housekeeping

Shane Kerr, IPv6 Working Group Chair, opened the first session. He briefly described the IPv6-only wireless network and encouraged everyone to use it.

B. IPv6 Campus Deployment Experience - Niall O'Reilly [FM1] , University College Dublin

The presentation is available at:
https://ripe68.ripe.net/presentations/261-RIPE68_Deploying_IPv6.pdf

Jen Linkova, Google, asked how many users or devices Niall expects for the wireless network. Niall said that he expects a couple of tens of thousands. Jen added that this large number of devices on the network may have an effect on the battery life of the devices. Niall thanked Jen for the warning and said that this would be an interesting user experiment. However, he agreed that, when adding a large number of customers, the noise level on the network goes up, which may be mitigated by the access control they're using.

Wilfried Wöber, Univie/ACOnet/VIX, said that they had been “playing with” IPv6 for a while at the NREN in Austria and that he was surprised to see in the most recent Akamai report that 43% of traffic with Akamai from Vienna University was IPv6 traffic, much higher than he had expected. Niall responded that this very much depends on the applications used.

Benedikt Stockebrandt, Stepladder IT, referred to a document from a university in South Africa. They turned on IPv6 on the campus and observed that 56% of the traffic was IPv6 and most of it was YouTube traffic. He expected that something like this will also happen at the Dublin campus and wondered what the traceability requirements are.

Niall answered that part of the agreement with Eduroam requires keeping radius and DHCP logs for six months.

Jen Linkova said that, before using tools to conform that a user is using a certain IP address which was assigned by DHCP (and not statically configured), one needs to consider that DHCP doesn't necessarily give you the malicious user that was using that address.

Niall responded that he is sure that they don't have complete proof against malicious attacks but that the majority of users want to use the network and the set-up, and the existing tools seem to be adequate for this purpose (logs from wireless controllers and access lists).

C. IPv6 Penetration in Hungary - Janos Zsako

The presentation is available at:
https://ripe68.ripe.net/presentations/330-IPv6_measurements_in_Hungary.pdf

Shane Kerr, Dyn, said that he was surprised to see that mail has such low penetration because it seems an easy thing to turn on. He asked Janos if he had any ideas why this is the case.

Janos responded that he doesn't know and that he didn't have the opportunity to talk to the providers to find out why this is the case. He added that it might be caused by the fact that it is not yet widely spread so the servers in the backbone or in the core could have IPv6 but that it doesn't help much yet.

Ondrej Calatka, CESNET, reported that he is operating automated responder tests, where you can send mail and take a reply over IPv6 and see if you are able to send to, and receive from, an IPv6-only mail server. He said that he observed some interesting things: 30% of MX records with IPv6 address don't respond to SMTP to connect to the port. Furthermore, when you are lucky enough to connect to the SMTP service, some IPv6-only host names respond with an invalid host name. There is also other anti-spam, anti-malware and other measures that are IPv4 only. So, even if you are communicating over IPv6 with the SMTP server, it means that you can only deliver mail with IPv6, therefore it's somewhat “horrible”.

Janos agreed and said that he also looked at common errors in MX records. Often, he saw local hosts or there are IP addresses inside or many other bugs.

Alex, participating via chat, asked whether the percentages shown are of MX, NS, WEB servers, or percentages of .hu domains with working service. Alex also asked, “Who are the champions of turning IPv6 on in .hu?”

Janos clarified that the percentage of servers that we see is much lower than the percentage of domains serving those servers. In response to Alex's second question, he stated that the academic network was one of the pioneers many years ago but he wanted to concentrate on the current situation.

Sebastian Castro, .nz Registry Services, reported that he sees similar numbers: higher level of adoption on name servers compared to adoption on mail and web servers. He added that they are scanning all domain names for A and AAAA records, that they are happy to share the data and that the IPv6 task force in New Zealand also has interesting numbers.

Jan Zorz said that he also sees the same issues with mail servers and suggested that people use protocols that work over IPv6 (such as DKIM). He referred to a recent article published by Frank Martin on RIPE Labs:
https://labs.ripe.net/Members/mirjam/sending-and-receiving-emails-over-ipv6

George Michaelson, APNIC, said that the different numbers Janos presented are because different people are measuring different things (mostly quantitative measurements). George commented that Janos is performing more qualitative measurements to assess capacity and capability, and it is common knowledge that that the centre is better than the edge. Therefore, it may not be surprising to see that the edge measurements Janos is performing are lower. Finally, he added that he was struggling to send traceroutes into IPv6 space in Hungary- the richness of the peering narrows pretty quickly.

Andrea Cima, RIPE NCC, referred to the quality of registration data in IPv6 as opposed to IPv4 data, as Janos mentioned in his presentation. The RIPE NCC has also been thinking about this: for IPv4 there was a much closer feedback loop between the RIPE NCC and the LIRs, especially when LIRs come back for more resources. For IPv6, that is not the case. Most LIRs will never come back for an additional allocation. Also, before 2011, LIRs were not required to register End User assignments in the RIPE Database. Recently, it was decided to create a new auditing process that is much more lightweight and focused on advice and support (the Assisted Registry Check, which has been very successful so far). The plan is to contact 3,000 LIRs every year and the RIPE NCC wants to make it easy for LIRs to maintain their resources.

An unnamed speaker from Romania said that they are running the biggest IPv6 network in the country. However, he added that they could not expand into Hungary, because the Hungarian regulator did not authorise lawful interception.

D. Painting by Numbers (Visualisation of Structured IPv6-Addressing) - Helge Holz, Dataport

The presentation is available at:
https://ripe68.ripe.net/presentations/344-Painting_by_Numbers.pdf

Jen Linkova congratulated Helge on this work and asked if it can also be used for other environments. She suggested making it public so that others can also use it. Helge said that, currently, it is not very stable but added that he certainly wants to make it public, which why he is presenting it at the RIPE Meeting.

Geoff Huston, APNIC, asked what would happen if the libraries would want to connect separately from all the schools.
Helge clarified that In Germany that won't be the case.

Niall stated that this algorithm has properties that he needs for his operations and that he couldn't work it out by himself. Therefore, he is very happy about Helge's algorithm and thanked him for it.

E. What the Future Holds - Ondrej Sury, CZ.NIC

Ondrej showed some slides from his presentation that was presented in full at the Open Source Working Group about Knot DNS. The full presentation is available at:
https://ripe68.ripe.net/presentations/262-KNOT-20140514-RIPE68.pdf

Wilfried Woeber asked for confirmation: if one has a particular entry for the 4-bit zone, you cannot automatically give the answer if queried for the reverse.

Ondrej answered that it is the case and that it doesn't match the zones together. It just creates a pattern that will generate “on the fly” if somebody asks for the name.

Session II: 15 May 2014, 11:00- 12:30

Scribe: Emile Aben

At the beginning of the session, Working Group Chair Marco Hogewoning mentioned the availability of an IPv6-only WiFi network.

F. RIPE IPv6 Analyser - Alex Band, RIPE NCC

The presentation is available at:
https://ripe68.ripe.net/presentations/338-IPv6_Analyser.pdf

There were no questions for this presentation.

G. BCOP Document: “IPv6 troubleshooting procedures for helpdesks” - Jan Zorz, ISOC

The presentation is available online:
https://ripe68.ripe.net/presentations/343-Jan_Zorz_IPv6_helpdesk.pdf

Ragnar Anfinsen, Altibox, said that he had received positive feedback on this from his helpdesk. He asked for additional text for expert users on the website, so that they can fix problems themselves.
Jan clarified that this is the plan.

Jen Linkova said that it's a great idea, and added that she had already given detailed comments by email. She wondered about the procedure and indicated that there are too many places to track and comment on this work and that it needs one place where discussion can take place.
After a discussion, it was agreed that technical comments should go to the IPv6 Working Group mailing list.

H. IETF document: “Balanced Security for IPv6 Residential CPE” - Ragnar Anfinsen, Altibox

The presentation is available online at:
https://ripe68.ripe.net/presentations/358-Balanced_Security_-_IPv6_Security_-_Ragnar_Anfinsen.pdf

Sander Steffann, SJM Steffann, said that this effort is heading in the right direction that it's very important to both show advice and experiences from people who have already done this.

Jan Zorz said that his suggestion at the IETF was to verify the document with the operational community, and mentioned BCOP as a means to do this.

Jan asked if the CPE (Customer Premises Equipment) vendors showed interest in this.

Ragnar said that they didn't show interest. This is mainly for service providers that manage the CPE and it is quite complex for retail CPE.

Jan suggested taking this to the openCPE project, or to Terrastream's version of that.

Benedikt Stockebrandt indicated that there are cultural differences on what approaches to adopt and it would be good to account for these.

Mathew Moyle-Croft, Amazon, suggested offering customers the ability to do upstream filtering, as an alternative to filtering on the CPE, as it's easier to manage and reduces traffic.
Ragnar said that the draft is about filtering as a service, and is therefore not necessarily specific to CPE.

I. RIPE_554bis - Sander Steffann, RIPE NCC

The presentation is available at:
https://ripe68.ripe.net/presentations/340-RIPE-554bis.pdf

Shane Kerr stated that this document is one of the success stories of this working group, but things need to be updated continuously.

Benedikt Stockebrandt said that the size of the document scares people off. He suggested to split it up in different documents addressing different areas, and indicated choosing connectivity as one of these.

Wilhelm Boeddinghaus, BCIX/Iubari, warned against setting the scope too wide and suggested keeping the focus with hardware, and not to engage in cloud or software-defined networking (SDN) because this will result in discussions. These, and connectivity need new documents.

Marco Hogewoning agreed with previous comments, and indicated that the document is widely used. He suggested adding text to the document on how updates to the document are handled. He argued to not obsolete ripe-554, “Requirements for IPv6 in ICT Equipment”, but make a new document that is referenced everywhere, to help people who are not familiar with the processes. He proposed keeping both ripe-554 and the new document alive.

Sander agreed, and considered different wording might help, and to not call it obsoleted.

Shane said that it wasn't clear to him how that would work.

Sander pointed out that ripe-501, “Requirements for IPv6 in ICT Equipment”, is called obsoleted and much downloaded, and called for careful communication regarding this.

Jan Zorz called for language polishing by native speakers. He added that, for the connectivity part, he is maintaining that list, and, due to an error, it wasn't in ripe-554. He volunteered to work on the connectivity part.

Sander said that he wants to do ripe-554 first, and later take the extra parts to the mailing list.

Mirjam Kuehne, RIPE NCC, indicated that the RIPE NCC is always happy to do language review of these documents.

J. IPv6 deployment at CERN - Edoardo Martelli, CERN

The presentation is available at:
https://ripe68.ripe.net/presentations/294-cern-ipv6-deployment.pdf

Jen Linkova asked about the plans for IPv6 on external services, because they are not dual-stacked.

Edoardo said that, internally, services are IPv6-ready, but are not externally ready for various reasons- for mail, due to lack of IPv6 support in their anti-spam software and for web server because they didn't dare to.

Shane Kerr wondered if they saw more questions coming into their customer support, because that was a concern for IPv6 World Day.

Edoardo said that most questions were about how to use it, not about problems.

Shane mentioned that there are people working to eliminate the need for Router Advertisement (RA), so to be able to use only DHCPv6.

Lionel Hoffmann, Bouygues Telecom, asked if the tools mentioned in the presentation were all homemade.

Eduardo confirmed that most of it is homemade.

Lionel also asked about experiences with specific applications having problems with IPv6, and CERN's plans for applications that only support IPv4.

Eduardo explained that they test whether applications keep working on dual-stacked machines, even if the application doesn't use IPv6. For some legacy applications, like AFS, he expected never to get IPv6 support, so they cannot phase out IPv4 at the moment.

Lionel asked if dual-stack is a step towards IPv6-only.

Eduardo answered that, currently, they expect to be dual-stacked forever.

K. Selection of a New Working Group Chair

Marco and Shane discussed David Kessens stepping down as one of the chairs of the IPv6 Working Group and how to fill the vacancy. Marco and Shane also intend to be gradually replaced. Working group chairs are replaced by consensus of the working group. They said that they would take the process to the mailing list. They then invited people to comment on this and to step forward as potential IPv6 Working Group Chairs.

Jan Zorz thanked David Kessens for his service and was willing to step forward as a candidate, but would need to work out how to combine that with chairing the BCOP Task Force.

Jen, Dave Wilson, HEAnet, and Dmitry Kohmanyuk, Hostmaster, also stepped forward as candidates.

Rob Evans, JANET, indicated that this is really good in the light of periodic reaffirmation of working group chairs. He was disappointed that Marco and Shane won't stand again.

The IPv6 Working Group chairs thanked participants for attending and stated that they hope that they would see the participants in London at the next RIPE Meeting. Marco Hogewoning urged participants to try the IPv6-only network and closed the session.