RIPE 65

IPv6 Working Group Session I and II - RIPE 65
Scribe: Alex Band (Session I), Matt Parker (Session II)
WG Chairs: David Kessens, Shane Kerr, Marco Hogewoning

Session 1: 26 September 2012, 14:00 - 15:30

A. Welcome and administrative items

• Agenda bashing
• Minutes of RIPE 64
• Announcements

B. Implementing IPv6 in RCS & RDS Network - Liviu Pislaru, RCS & RDS

The presentation is available at: https://ripe65.ripe.net/presentations/135-RDS-IPv6-ripe65.pdf

Lorenzo Colitti, Google, commented that Liviu has real working v6 on the network and that address needs will mostly come from new customers. If those customers have an IPv6 capable CPE, they can just use something like MAP instead of NAT, and use stateless solutions.

Marty Hannigan, Akamai, commented that the traffic stats were particularly impressive. He added that the entire Akamai platform is IPv6 enabled but on World IPv6 day, customers had to opt-in, which is why you would see mixed results on that day for Akamai traffic. With regards to the latency, he said he was going to research why that occurred and report back.

Gert Doering, Address Policy WG co-Chair, said that he is happy that Liviu is showing the world that this kind of IPv6 deployment can actually be done. He added that Germany has had IPv6 for about 15 years, but no large broadband provider is offering it. He hopes that this example will make things happen.

Lorenzo asked if large broadband providers in Germany are using the same technology as RCS & RDS use.

Jan Zorz, Go6, said he hoped that there would be more presentations like this from different countries. Jan said he gathered from Liviu's presentation that he was planning to move from dynamic /64 delegations to /56. He asked if he was planning to make it static or if they would continue to use dynamic "madness".

Liviu responded that they will continue to use the dynamic /56 addressing scheme for residential customers. For business customers they will use a static /48 delegation.

Tahar Schaa, Cassini Consulting GmbH, asked if the DD-WRT CPE firmware they adapted for this project is available somewhere.

Liviu replied that he's happy to offer the image.

Lorenzo commented that you can just buy a D-Link or Linksys CPE and it'll support IPv6. He said you could go to the World IPv6 Launch web pages and can find information about IPv6 capable CPEs. He added that his point was that you don't need to customise a DD-WRT firmware to get v6 support nowadays.

C. World IPv6 Launch - Yannis Nikolopoulos, OTE

The presentation is available at: https://ripe65.ripe.net/presentations/139-ripe65-yanodd-ote-depl-w6l.pdf

Mark Townsley, Cisc, clarified that OTE's World IPv6 Launch issues only affected single-stack customers. He suggested to just give everybody dual-stack to solve the problem.

Yannis replied that this was easier said than done.

Mark Townsley, Cisc, commented that if you can't solve a problem with a certain vendor, you should simply change vendors.

Lorenzo Colittli, Google, asked if all of the CPEs in the field that are causing issues are going to be replaced.

Yannis responded that they would be replaced if the new firmware doesn't solve the issue, but that it wouldn't happen overnight.

Lorenzo asked, assuming the CPE issues never get fixed, does it mean that you can never deploy IPv6.

Yannis replied that there are also other issues at play, like the fact that they're moving from ADSL to VDSL. In total, they're looking at around 50,000 to 100,000 customers. In addition, OTE is deploying a lot of new IPv6-capable CPEs that don't have any issues.

Lorenzo replied that until all v6 issues are resolved, v6 cannot be deployed.

Yannis said that the issue affects 20,000 CPEs out of 1.4 million.

Lorenzo said that there would be some other networks in the world with the same CPE who could be suffering from the same issues. It would really help if OTE discloses manufacturer name.

Yannis said no.

Alan Steel, via chat, asked if it wouldn't be easier to just disable IPv6 in that particular CPE setup.

Yannis responded that this is an option that they considered, and it's still on the table in case the new firmware doesn't solve the issues.

Eric Kline, Google, asked if OTE would consider a Hellenic IPv6 launch event.

Yannis said he was a bit unclear on what an event would entail.

Eric commented that Japan had a similar event to attract attention to IPv6 and that the same might be beneficial for the Greek community.

Yannis replied that the OTE has a task force to promote IPv6.

D. IPv6 deployment in Forthnet - Anastasios Chatzithomaoglou, Forthnet

The presentation is available at: https://ripe65.ripe.net/presentations/171-Forthnet_IPv6_-_RIPE_65_-_26.09.2012.pdf

Shane Kerr, ISC, asked about the PCP requirement and commented that PCP is still being standardised.

Anastasios confirmed that they have CPE beta firmware based on the drafts.

Jan Zorz commented that DS Lite is a terrible idea and there are better options available now. He added that he really liked the timeline and commented that the general theme of the projects shared today show that they take a lot of time.

Shane Kerr, ISC, asked why Forthnet does not use a DHCP IPv6 server.

Anastasios responded that they currently don't have any service that uses DHCP and they don't want to go with custom hardware.

Mark Townsley, Cisco, said that there are better alternatives than DS Lite available. He asked if there was a moment when Forthnet thought that they should stop and focus another project.

Anastasios responded that they would have considered that if they had more tim. The reality is that it took them 18 firmware revisions to get to the point they are now. It's a complicated process.

Marks said that MAP would work better for them.

E. IPv6 CPE Survey 2012- Marco Hogewoning, RIPE NCC

The presentation is available at: https://ripe65.ripe.net/presentations/205-CPE-Survey.pdf

Lorenzo asked for a feature request to have two fields added: one with the post-interoperability test, the other where you would link to a page where the results of the test are stored.

Mark Townsley, Cisco, said that when considering transition techniques, the overview should only display true IPv6 functionality and those that are actually available from a service provider, so things like IPoE, PPPoE and 6RD. This means leaving things like DS Lite and MAP out, which offer IPv4 connectivity.

Tahar Schaa, Cassini Consulting GmbH, asked to have alternative firmwares like DD-WRT listed.

Marco replied that they deliberately focused on CPEs that provide off-the-shelf functionality.

F. IPv6 RIPEness- Emile Aben, RIPE NCC

The presentation is available at: https://ripe65.ripe.net/presentations/200-ripeness-morestars-emileaben.pdf

Jan Zorz thanked Emile for bringing weighting into the system. He said he thinks that the results will be less unfair.

Wilhelm Boeddinghaus, Strato Germany, commented that he didn't like the weighting because Google and Facebook always skew the numbers. Strato has about four million domains that are IPv6 capable, but none of them make it onto the Alexa list because they're not nationally or even regionally used. He said he thought the sheer number of websites could be an important metric as well.

Emile clarified that big hosters are depending on their customers to turn on IPv6. So if you have 1,000 websites in the Alexa 1 Million, then they will just weigh those.

Iljitsch van Beijnum asked why the RIPE NCC is considering changing the limit.

Emile responded that everybody should really deploy IPv6; this year's 1% is next year's 2%, so why not.

Iljitsch replied that when you do, you can't compare the numbers over the years.

Marco asked about showing Provider Independent End User space. Emile says that that can be measured separately if people are interested.

Session II

H. Welcome back

David opened the session and welcomed the attendees. He noted that the presentations and topics in this session would be IETF oriented. He introduced his co-Chairs, Marco Hogewoning and Shane Kerr.

I. L2 issues and solutions - Eric Vyncke, Cisco

The presentation is available at: https://ripe65.ripe.net/presentations/129-vyncke_-_layer-2_security_ipv6_RIPE65.pptx.pdf

Benedikt Stockebrand, Stepladder IT, commented that the reasoning Eric gave in his presentation (regarding the remote attacks) was very important. He said that another way to prevent L2 issues is to put machines that don't trust each other in separate networks and that this is the most fundamental design in a lot of cases.

Eric agreed that this was what he was talking about with host isolation. He explained it as a single host but it could also be applied to a group of hosts.

Benedikt added that they now have working multicast routing. Therefore the one reason that forced them to put machines into the same network (broadcast routing – or the lack of effective IPv4 multicast routing) is gone. This can help to solve a lot of problems with minimum effort.

Iljitsch van Beijnum, bgpexpert.com, added jokingly that it seems to be a bad idea to be on the same Layer 2 network as someone who is planning to attack you.

Eric agreed with the point and replied by asking, rhetorically, whether Iljitsch was using the WiFi network at the conference.

J. IETF work on operational security for an IPv6 network - Merike Kaeo, Double Shot Security

The presentation is available at: https://ripe65.ripe.net/presentations/241-RIPE65-v6sec-in-opsec.pdf

Merike Kaeo asked the audience if anybody was using SEND in their environment.

Nobody responded.

Iljitsch van Beijnum, bgpexpert.com, asked whether anybody in the room would like to use SEND if it was possible for them.

Marco Hogewoning, WG co-Chair, counted four hands raised.

Benedikt noted that there is one reason not to use SEND; as soon as you use cryptography in any way you are requiring extra CPU cycles and therefore are more vulnerable to DoS attacks. The combination of remote attacks and the operational requirements of SEND could cause the routers to struggle with CPU load. This is perhaps another reason why SEND is not being used.

K. KATR Catalogue of (IPv6) routers - Ondrej Filip, CZ.NIC

The presentation is available at: https://ripe65.ripe.net/presentations/234-KATR-Ripe-2012-09-1.pdf

Jan Zorz, Go6, asked Ondrej whom they were communicating with at the committee.

Ondrej replied that he was not sure and added that they had wanted to get the status of “IPv6 approved laboratory” but that the process had taken more than three years so they had decided not to proceed.

Jan explained that the IPv6 Ready Logo group is busy working on the specifications for their tests – they expect this to be completed in November 2012.He asked Ondrej whether cz.nic had already specified all of their tests.

Ondrej responded that it was possible and suggested meeting up outside of the session to work on this together.

Merike Kaeo, Double Shot Security, commented that this was really important work. She said she also performed some testing of CPEs advertised as IPv6 compliant and experienced some problems. She wanted to configure a /64 on her WAN, a/64 on her LAN and enable two v6 DNS servers. Unfortunately the majority of devices could not support that. The devices that would support the setup required manual configuration of IPv4. She asked Ondrej whether they could also test the CPEs to check if the run native IPv6.

Ondrej confirmed that they do test whether the CPEs work without IPv4 but that he is not sure if it includes supporting all of the features that Merike mentioned. They will think about adding this to their specifications.

L. IETF Work on transitioning techniques for multicast traffic - Tom Taylor, PT Taylor Consulting

The presentation is available at: https://ripe65.ripe.net/presentations/133-RIPE_IPv6_-_Multicast_Transition.pdf

David Kessens, IPv6 Working Group co-Chair, remarked for the record that this is a ‘Working Group'. Therefore, if Tom proposes something and receives input he is happy about that.Even if sometimes it is a negative conclusion, that is fine, we are all here to work together.

M. Why NAT64 must win - Andy Davidson

The presentation is available at: https://ripe65.ripe.net/presentations/246-nat64-must-win.pdf

Shane Kerr, ISC, thanked Andy for the controversy. He asked Andy to clarify his statement that MAP doesn't address the issue of exhaustion.

Andy explained that as your user/subscriber base grows you have to pinch more ports from users, which will “spongify” their user experience.

An audience speaker asked Andy to clarify the term “spongify”.

Andy explained that if you reduce the number of ports available to a user they become unable to use more interactive applications.

Shane remarked that NAT does the same thing.

Andy concurred.

Shane commented that NAT is necessary for this type of transition technology and therefore MAP addresses conservation in exactly the same way that any other NAT port translation does.

Andy replied that it addresses conservation in the same way that CIDR did – it takes a number of addresses and enables us to use them more effectively by thinking in new ways about efficiency.

Shane said that this is all they could ever hope for. He asked if Andy is a fan of NAT 64 because it adds pain.

Andy replied that it provides an incentive to avoid pain – a good incentive in his opinion.

Lorenzo Colitti, Google, said that Shane's point is that NAT 64 and MAP do exactly the same thing regarding exhaustion. So NAT 64 can't claim an advantage over MAP on that point. Lorenzo noted that the main problem with NAT 64 is that it is not deployable today. He added that Cameron would like to deploy NAT 64 but he cannot because no manufacturer will ever ship a device that cannot run Skype. This is in an environment where terminals churn every two years, the network is ready and, per Cameron's studies, 90% of apps do support v6. Lorenzo added that you couldn't use an imperfect substitute to replace what you have today. So the closest thing is 464 but that's IPv4 over carrier pigeon, you can't run it on a wireline network.

Lorenzo also questioned what the band reconditions would need to be for them to be able to deploy NAT 64 and when the breakage would be acceptably low enough. He didn't think they were at that point yet.

Andy agreed that this is a point he wants to reach and that if they want to take genuine steps towards a v6 native end-to-end Internet, the transitional technology that they choose needs to take account of that. He added that MAP would probably cause fewer breakages than the other transitional technologies that require users to have v4 address space of some kind. This is because there is less state in places where you don't want state. His added that the long-term view is the most important and that ultimately they should be able to turn off these transitional technologies.

Jan stated that the idea of A plus P was to give an alternative to evil, fat, big stateful CGN. MAP is a stateless version of A plus P that is well defined and has been further developed by guys from Cisco. He asked Andy why he is suggesting that a stateful solution is the best one to choose.

Andy responded that this is definitely the long-term view. If he had to pick a technology today, which he needed to use tomorrow, he would choose MAP. However, what he would like to see in five years time is an Internet that can cope with NAT64 for new builds. It provides the last bit of incentive that may be necessary to turn off transitional technologies in the future. He said that they get the Internet that they deserve.

Jan asked if Andy could put in his slides at the beginning that stateful is bad.

Andy replied that stateful is always bad, pain is bad, but there is a place for it.

Benedikt noted that pain is actually good in this situation because it makes people change their habits. He added that a lot of people don't realise how painful the lack of support for literal IP addresses is. He also noted that a transitional technology that can be useful for business customers (though not for home users or ISPs) is Application Gateways.

Andy responded that in his opinion Application Layer Gateways could be more painful than putting state in place where NAT64 does.

Benedikt replied that they are less painful if you have to use them anyway for security reasons and if you can get away with using them and nothing else.

Ondřej Caletka, CESNET, z.s.p.o., mentioned that NAT64 needs DNS 64 to operate and, by design, DNS64 breaks DNSSEC.

Iljitsch van Beijnum, bgpexpert.com and co-author of DNS 64 and NAT 64, explained several scenarios for the implementation of DNS 64 and DNSSEC showing how common problems could be avoided. Iljitsch asked whether people in the room would be interested in asking the IETF to start working on ways to make literals work through NAT 64.

No hands were raised.

Mark Townsley, Cisco, said that the stateless technologies like 6RD and MAP can be run inline with the existing edge routers. So unlike stateful technologies like DS Light, NAT 444, and even NAT 4 you don't need to add a bunch of special purpose boxes.

Andy acknowledged this but reiterated that it does not address the exhaustion issue. He added that there are reasons to like and dislike all of the transition technologies but in his opinion none of them will be perfect because none of them are native IPv6.

Erik Kline, Google, applauded Andy's focus on supporting native IPv6 and commented that if there were an ISP providing a NAT64 IPv6-only service in his area then he would buy it and try it.

N. Results of the 2012 Global IPv6 Survey - Maarten Botterman, GNKS Consult

The presentation is available at: https://ripe65.ripe.net/presentations/127-RIPE_65_Global_IPv6_Deployment_Survey_2012_highlights.pdf

Ivan Beveridge, Betfair Ltd, asked who the target group was for the survey.

Maarten responded that the population was invited to respond via the RIR mailing lists. About one third were ISPs and the rest were other parties. The population hasn't changed significantly over time so the results are comparable to previous surveys.

O. Wrap up and discussion on future work

David Kessens, IPv6 WG co-Chair, remarked that it was a little unfortunate that this session ran in parallel with the Address Policy Working Group session – they would work to ensure that this wouldn't happen again. He thanked everyone for attending and closed the session.

P. Closing