IPv6 Working Group Minutes RIPE 70

Session I

14 May, 9:00 - 10:30
Scribe: Mirjam Kuehne
WG chairs: Jen Linkova, Benedikt Stockebrand, Dave Wilson

A. Welcome and Administravia

Jen Linkova opens the session.

B. HTTP State Management (Cookie) in an IPv6 World: Apply Caution! Eric Vynke, Cisco

The slides are available at:
https://ripe70.ripe.net/presentations/124-ripe70-ipv6-vyncke-state-management-template.pdf

Wilhelm Boeddinghaus, iubari, added that Windows 7 and 8 use a temporary address for outgoing connections. The time frame for outgoing connections is usually one day, but if one turns that down to one hour, it could happen in the middle of a session. So one doesn't need IPv4 and IPv6 for changing addresses. One can do it with IPv6 only.

Erik Vyncke agreed and said that the same applies for IOS devices that simply change IP address every time they wake up.

Jan Hugo Prins, better.be, commented that this problem is older than IPv6. As a hosting provider, they decided to turn off IP checks a long time ago. Most of them don't work, so he suggested to simply use HTTPS.

Erik agreed with this comment.

Iljitsch van Beijnum, BGPexpert.com, added that this is mostly a CGN problem, not specific to IPv6. As far as he understands, people make these cookies in order to avoid stealing cookies which is a big security problem. So, what is the solution? And how can we get it to work?

Erik responded that he also doesn;t have a solution and he is asking everyone for help. Maybe we can slowly relax the link between the cookie and the IP address.

C. Use Cases for IPv6 Extension Headers - Let's Do Some Marketing - Wilhelm Boeddinghaus, iubari

The slides are available at:
https://ripe70.ripe.net/presentations/118-RIPE70-IPv6-Boeddinghaus.pdf)

Benedikt Stockebrand, Stepladder IT Training+Consulting GmbH, commented that there is one major issue with extension headers which is that they are not appearing in a fixed order. That makes it very difficult to deal with them in hardware for instance. He suggested that the IETF cleans up what we have and deprecate what's not needed. But operators also have to provide input to the IETF.

Wilhelm said that he can imagine the discussion at the hardware vendor when the protocol guys come and say they would like to have new hardware built for extension headers: “Is anyone using it?” “No, but it is in the standard.” As result the vendor will not implement it if they are no use cases.

Jen said that since we were talking about use cases, she would like to add that there are probably use case we don't know about, because they might only be used in internal networks. She added that several years ago, we didn't know if there are use cases for routing headers, and now they are widely used. She said she would strongly advise to get rid of them because we are not aware of use cases.

Nathalie Trenaman, RIPE NCC, agreed and said that during the RIPE NCC IPv6 training courses she spends a serious amount of time explaining to people that when they design an IPv6 network, they might not know yet what they are going to use this enormous amount of address space in the future. It's a whole philosophy change that you give people a /48 even though they don't know yet how the addresses are going to be used. The same applies to extension headers: we don't know yet how we will use them in the future of the Internet. She said she understands why people are filtering them now (basically for security reasons). But we don't know how bad this is at the moment, and how bad it will be in the future when we find a use case and we have to tell people to stop filtering. In
the end we might have to reverse things which might be difficult.

Wilhelm ensured the audience that he is not advising people to deprecate extension headers. But he is concerned that newcomers to the protocol fear these headers, because they don't know what they are used for and hence filter them out.

Erik Bais, A2B Internet, mentioned that the equipment he is using supports extension headers until 4 or 5 headers. After that they drop the packet. He wondered if we actually need equipment that supports more extension headers.

Wilhelm suggested to write a document that clearly describes use cases that define a finite number of headers (maybe up to three?). But for more than that defined number (the maximum possible number is 15), it could be suggested to filter for instance.

Jen mentioned an Internet Draft that says your firewall should be able to distinguish between the different situations based on the protocol.

Jan Zorz, ISOC, added to Erik's comment that he is annoyed by people just filtering out packets without looking deeper into them and without making a distinction if they are valid or not. He advised people who filter packets just based on extension headers, to stop doing this.

D. OS Behaviour in Contradicting Environments - Christopher Werny & Enno Rey, ERNW

The slides are available at:
https://ripe70.ripe.net/presentations/132-ERNW_RIPE70_IPv6_Behavior_Conflicting_Environments_v0_92_short.pdf

Enno Rey took the opportunity to advice that extension headers should be deprecated and to mention that they did many studies that showed that they pose a security risk.

Steven Barth, OpenWrt, said that he could understand the behaviour of operating system vendors, because he sees it from the side of the CPE (customer premise equipment). He described the difficulties for both sides and said that they have to deal with each other in a sensible way.

Ahmad Alsadeh, Birzeit University, agreed that this is confusing. If one goes further and considers security, one has to look at auto-configuration that becomes an automatic process. He further asked what the impact of DHCP6 is, especially because at the beginning of the IPv6 specification there was consideration to get rid of DHCP.

Enno responded that he would like to re-direct the question to the 6man (IPv6 maintenance) working group at the IETF. But he agreed with the perception that DHCP was more a side development and not considered very
important. Now after twenty years it is still considered a niche.

Iljitsch van Beijnum reported that he was involved at the IETF during the discussions about DHCP6 and auto-configuration. In response to Ahmad he said that DHCPv6 was actually not removed from IPv6, because
DHCP didn't exist when they started working on it. On has to remember that IPv6 is the successor of the IPv4 of the early 1990s that was very different from the IPv4 of the late 2000s and 2010s. Finally, Iljitsch mentioned that he was happy to see that Enno wasn't suggesting writing more RFCs. People implement weird things, because they don't read the RFCs that exist already, so adding more would not help.

E. IPv6 for ISPs - Aaron Hughes, ARIN

(slides: https://ripe70.ripe.net/presentations/133-IPv6-for-ISPs.pptx)

Pierre Smith, Orange, thanked the speaker for pointing out that this is not all shiny yet and added that he agrees that this is often a management problem, because they don't understand what this is all about.

Aaron asked the audience if it would be useful to regularly report on the state of IPv6 at ISP, maybe by way of a survey or some sort of a metric?

People nodded.

Jan Zorz said he appreciated the report about the current state of IPv6 at the ISPs. He added that is surprised to hear that we still talk about IPv6-enabled and IPv6-compliant. He was hoping this was cleared that up with ripe-554 document and suggested Aaron to share this document with his community.

Aaron told that in order to help a client who had a requirement to install IPv6-enabled equipment. So, he went to buy a printer that said it was IPv6-enabled and as soon as he switched it on, it found the IPv6 address and turned off IPv4.

Peter Hessler, Hostserver GmbH, noted that for people that were implementing dual stack it's important for them to also test the v6 pure network, maybe not deploy it yet if it doesn't make sense for them, but to keep that in mind that you are likely to run into a lot of problems.

IPv6 Working Group - RIPE 70 - Draft Minutes

Session II

13 May 2015 16:00 – 17:30
Scribe: Marco Hogewoning (RIPE NCC)
Dave Wilson (co-chair) reopened the session and welcomed everybody.

B. WG Chair Replacement Procedure Discussion

The presentation is available at:
https://ripe70.ripe.net/presentations/162-ipv6-wg-chair-selection-ripe70.pdf

There were no comments and the procedure was approved by acclamation.

C. IPv6: Who Is and Who Isn't? - Geoff Huston, APNIC

This presentation is available at:
https://ripe70.ripe.net/presentations/129-2015-05-14-ipv6-stats.pdf

There were no questions or comments

D. Lightning Talks

D1. IPv6-Only Network @RIPE70 - Jen Linkova, Googlt

This presentation is available at:

https://ripe70.ripe.net/presentations/149-IPV6-Only-Network-%40RIPE70.pdf

Aaron Hughes, 6connect, asked if the configurations could be shared so people could conduct their own experiments. He also suggested to switch the primary meeting network to IPv6-only.

Marco Hogewoning, RIPE NCC, explained that this was discussed, but there was too much risk and the working group had to ensure nobody would run into problems.

Blake Willis, L33 Networks, pointed to the archives of the Athens meeting that contain code samples. He also asked whether the group could publish a “name & shame” list of companies and products not supporting IPv6-only. Adding that the use of 464XLAT could make swapping the primary network easier.

Jen answered that there is a Wikipedia entry that lists the problems and it would be updated based on the experience at this meeting.

Dmitry Kohmanyuk, Hostmaster UA, asked if DNS statistics were available.
Jen referred to a later discussion about public DNS64 servers.

Sasha Luck, via chat, asked if stateless DNS64 could be provided. After clarification by an audience member, Jen answered that the stateful solution in place was fine and changing it would be difficult.

Jan Zorz, ISOC, mentioned he had some public DNS64 servers in his lab and also asked to activate 464-XLAT.

Dave Wilson asked the working group to consider if it is worth the resources to sustain this experiment, inviting people to discuss this on the mailing list.

Dmitry Kohmanyuk suggested dropping the term “experimental”. Jen responded that they needed to make it work first.

D2. Lost Stars - Nathalie Trenaman, RIPE NCC

The presentation is available at:
https://ripe70.ripe.net/presentations/119-Nathalie-LostStars-v6wg_v2.pdf

An audience member asked whether it was caused by more specifics.
Nathalie explained this wasn't the case.

Eric Vyncke, Cisco, suggested it was due to bankruptcy, Nathalie said the LIRs were still in business and open.

Iljitsch van Beijnum, BGPexpert.com, made the suggestion to correlate this to IPv4 announcements from the same LIR. Nathalie thanked him for the suggestion.

D4. 554, 631 - What's the Next IPV6 Speed Bump? - Jan Zorz, ISOC

The presentation is available at:
https://ripe70.ripe.net/presentations/166-Jan_Zorz_IPv6-WG-what-next.pdf

Benedikt Stokebrand, Stepladder IT, commented that there is a lack of Best Current Practice that take an enterprise point of view. Sander Steffann expressed his support for this statement.

Jan Hugo Prins, Better.be, said that big companies use NAT and are afraid to open up their networks by deploying IPv6. He also mentioned that Spotify did not work on the IPv6-only network.

Eric Vyncke said he wrote an RFC with focus on enterprise and suggested to not repeat the work already done. Benedikt responded that RFCs are hard to read and scare people away and suggested to create easier
accessible documentation.

D3. Software & IPv6 - Nathalie Trenaman, RIEP NCC

Nathalie told the audience about her experience with training people and the questions they get frequently asked. One observation is that a lot of people point to the man-hours and associated cost of modifying
OSS/BSS systems to support IPv6 deployment. She suggested to get software developers more involved and asked the working group for their feedback.

Benedikt Stokebrand pointed out the situation can be far worse with software such as Cobol which are not so easy to modify. He mentioned that often the problem starts with picking the right software libraries for the job and figuring out what to fix and how to fix it, is half the work.|

Wilhelm Boeddinghaus, Iubari, suggested to change the messaging and focus on the cost savings of making sure all investments are IPv6 ready instead of focusing on the costs of deployment.

Nathalie responded that her suggestion was to focus on the people writing the code and to educate them.

Wilhelm responded that in order to do so, you also need a good lab environment that allows people to test things.

E. IPv6 Deployment Bumps Discussion/Brainstorming Session - Jen Linkova, Google

The presentation is available at:
https://ripe70.ripe.net/presentations/153-V6_Deployment_Bumps.pdf

Peter Hessler, Hostserver, explained they are a content provider and their two major blockages where the lack of support in advertising networks and monitoring services.

Jen commented this was possibly due to a broken chain between developers and network people and suggested to do some more capacity building, asking people to suggest which venues and groups would be the best target.

Silvia Hagen, Swiss IPv6 Council, said it was an awareness problem on the side of the developers who are hiding behind frameworks. She mentioned not that many people really understand what is needed to develop IPv6 support and suggested to create some high-level documentation about that. She added that there is also a need to figure out a way to test legacy codebases.

Jan Zorz, ISOC, suggested to use competitive pressure.

A participant mentioned the need to share experience and configuration examples,, using XS4ALL as an example.

Marco Hogewoning (former XS4ALL employee) responded that his presentation in the meeting archive contained example code from the XS4ALL deployment.

Timo Hilbrink, XS4ALL, offered to present about this again at the upcoming meeting, asking the chairs to allocate him a slot.

Somebody mentioned that they started to deploy IPv6 with their management network. Jen responded that could be an attractive strategy as mistakes are less visible.

Jen Linkova wrapped up the discussion and thanked everybody for their participation and closed the meeting.