Dear working group, As a reminder, there are still some days left to leave your comments or corrections. We, the chairs, would at minimum appreciate some acknowledgements that you have read these and didn’t have any comments. It is very hard to make a decision based on silence. Thank you, MarcoH On 06 Mar 2014, at 15:44, Marco Hogewoning <marcoh@marcoh.net> wrote:

Dear working group,

Attached are the draft minutes of the RIPE 67 sessions, as prepared by the RIPE NCC. Apologies for the delay in getting these published, as you can see it is a rather long document this time.

Please have a look and report any errors or omissions to this list or directly to chairs.

Deadline is 10 april 2014, after which we hope that we can conclude there is consensus to publish these on the website.

Again thanks for your cooperation and the lively debates we had in Athens and hope to see you back in Warsaw.

Regards,

MarcoH on behalf the IPv6 WG chairs — IPv6 Working Group Date: 16 October 2013, 14:00 - 15:30 Chairs: David Kessens, Shane Kerr, Marco Hogewoning Scribe: Emile Aben

Session I

A. Welcome and Housekeeping

Marco Hogewoning opened the first session. The minutes from the last IPv6 Working Group session at RIPE 66 in Dublin were approved.

B. Global State of IPv6 Deployment Since IPv6 Launch Geoff Huston, APNIC

The presentation is available at: https://ripe67.ripe.net/presentations/115-2013-10-16-ipv6-launch-365.pdf

Blake Lillis, L33 Networks, was wondering if IPv4 is actually getting worse rather than IPv6 getting better.

Geoff said he doesn't think it's IPv4 getting worse. It is actually pretty amazing to see that IPv6 is getting faster and better.

Lee Howard, Time Warner Cable, confirmed that this is consistent with what he is seeing in their network: most of the time IPv6 is performing better. He asked Geoff if he had any guesses as to why.

Geoff said he doesn't at the moment but will look through the data for clues.

Tore Anderson, Redpill-Linpro, noticed that Opera was on the slides. They are running a proxy service for their browser. Their users are not necessarily on IPv6, they are not even in Norway, and the servers are not in the country either. But it makes Norway look good. He asked if Geoff is counting the number of hits, or the number of addresses.

Geoff responded that they are indeed counting the number of hits.

Tore noticed that Google's data for Norway was up to 9%, and was wondering if Geoff should compensate for the Opera case.

Geoff said the best way to top IPv6 statistics is to deploy IPv6.

There were no further questions.

C. Terastream IPv6 Details Peter Löthberg & Mikael Abrahamsson, T-systems

The presentation is available at: https://ripe67.ripe.net/presentations/251-ripe2-4.pdf

Peter stressed after his presentation that he is really looking for feedback.

Geoff Huston pointed out that the current IPv6 address policies doesn't seem to correlate with what Peter is trying to do.

Peter said this is why this is presented here at the RIPE Meeting, which is the forum that develops address policy in this region. This is something that wasn't really anticipated when we started with IPv6. That's why he is looking for feedback here. He tried to convince people to use variable length addresses, but that was refused in 1994. But how many bits will be needed is what needs to be discussed here. He is suggesting to use address bits to build a better Internet. But he really needs feedback from the community, especially before this will be implemented.

Geoff agreed and stressed that this is certainly a change that one needs to think about.

Peter explained that when they were not allowed to do variable length addresses back in the 90s, they came up with extension headers. So, even if things today, there is still enough for the future.

Mikael clarified that they are not proposing to use more addresses for customers than is allowed by policy today.

Peter added that someone was saying that giving a /56 to customers is overkill. But he really wants to avoid putting a NAT box in.

Martin Levy (Hurricane Electric) asked if there is anything in the IPv6 address you are exposing to the world that you maybe shouldn't be exposing? And haven't we learned by now that if we do static splits in the address, we're going to run out at some point.

Peter explained that there is no information here that you don't also have in any other IPv4 system today. Some bits tell you the geography, some tell you something about the network topology. But they can be randomised like it is happening in IPv4. He said he has a hard time understanding why people worry about that while they carry a phone with a fixed phone number. And no, he is not worried to run out of addresses anytime soon.

Peter further elaborated on programmatic responses for reverse DNS for IPv6 address blocks and mentioned DNSSEC being a problem in that. There is a possible DOS against generating a programmatic answer and then sign it on the fly.

Scott Leibrand (Limelight Networks) said he's failing to capture the exact magnitude of the address block Peter is planning to request from the RIR. He's not so worried about the 6 bits-part, but more about the 13+14 bits, which is more relevant to the potential of exhausting IPv6 space.

Peter said he wanted to show the concept, that's why there are no actual numbers on the slides. After more discussion on bit-level details Scott and Peter decided to discuss this further face to face at a later time.

Dimitris Kalogeras (GRNET) pointed out the need for a trigger mechanism if prefixes disappear at a specific time. Currently there is nothing like that yet in operating systems. He was also curious as to why Peter didn't use the diffserv approach.

Peter answered that the trigger mechanism merits a longer discussion. And he wanted the customer to be able to use the DiffServ bits.

There were no further questions.

D. NIC.CZ GEN6 Project Zuzana Duračinská, CZ.NIC

The presentation is available at: https://ripe67.ripe.net/presentations/210-CZ.NIC_GEN6_ZuzanaDuracinska.pdf

Alexander Isavnin, NetLine, noted that IPv6 adoption in Russia is very low and asked if the results Zuzana presented correlate with any European programs to deploy IPv6.

Zuzana responded that in this particular case they have looked at GEN6. Inside the country they are also collaborating with many different organisations. But deployment in governments take a long, long time.

Lee Howard, Time Warner Cable, thanked Zuzana for this presentation and said it was very useful. He mentioned that he would love to see collaboration to compare policies by country and to see which policy helps the most to encourage IPv6 deployment. One effort is to show that access to IPv4 is getting more expensive.

Zuzana answered that people have to realise that it is not just about websites. There are going to be more and more online services and we won't be able to do it without IPv6.

There were no further questions.

E. Case Study: An ISP IPv6 Addressing Plan - Yannis Nikolopoulos, OTE

The presentation is available at: https://ripe67.ripe.net/presentations/222-ripe67-yanodd-ipv6-addressing.pdf

Shane Kerr, ISC, commented that he felt the study was very interesting in concept and noted that it was somewhat similar to the proposal made by Peter Lothberg in the first IPv6 session.

Yannis responded that he was afraid to mention the similarity. Shane noted that Yannis had different goals and usage of the bits when compared to Peter Lothberg, but noted that the basic idea of encoding information other than raw topology and aggregation into the address was quite interesting. Shane continued that the IPv6 Working Group does not have the tools to evaluate this, so proposed moving it to the list.

Yannis agreed, commenting that he was going to propose moving it to the list, too. Shane responded that this was normal procedure, and hoped that there would be good consensus in that this kind of experimentation is the way forward.

Marco Hogewoning agreed that this would be followed up on the list.

Rüdiger Volk, Deutsche Telekom Technik GmbH, commented that he was guilty of talking about using a few address bits in IPv6 for semantic purposes since the RIPE 50 Meeting in Stockholm. He continued to elaborate on his experiences in IETF when this kind of address usage is presented and leads to complaints from senior architects. Rüdiger then commented that address space and bits should not be used for ‘administrative convenience’, or we would need IPv7 soon. He stated that if operational and forwarding semantics are very carefully defined to the bits, then too much space is probably not burnt up. In his opinion, this proposal went too far in the direction of administrative convenience.

Marco stated that, as Shane had suggested, this would be taken up on the IPv6 Working Group Mailing List, and thanked Yannis for his presentation and flexibility in scheduling.

There were no further questions.

F. Small Scale Redundant IPv6 Uplinks without BGP Benedikt Stockebrand, Stepladder IT

The presentation is available online at: https://ripe67.ripe.net/presentations/249-presentation.pdf

Tore Anderson, Redpill Linpro, stated that, in his organisation, they are doing something that solves the problem in a simpler way than any of the solutions offered. They are getting a provider-independent (PI) block, for the end user, but are not running BGP to the user – simply originating the prefix for them, as does ISP B. This way, these parties don’t need to learn BGP, but have stable addressing and if the link from their downstream interface to the customer goes down, the route disappears from their IGP, and they can immediately stop announcing it to the world and so does ISP “B”. So if they want to force the traffic, the customer can just shut down the interface and it will automatically converge. He stated that they had been doing this in IPv4 as well as in IPv6 for several years.

Benedikt responded that this would be very expensive, due to the extra routes in the default-free zone; other people would pay the bill for this because they would need to pay for the extra memory.

The attendee responded that this is the case with IPv4 PI space and that is what the IPv6 community has agreed to allow.

Benedikt stated that this was correct, but commented that everything is getting larger – the default-free zone, the routing tables – faster than we can keep up with, in terms of extra memory, larger routers and highly reliable network connectivity. He stated that he doesn’t expect this to work in the long run.

The attendee pointed out that IPv6 PI graphs are shown at every address policy meeting and these show no explosion of IPv6 PI.

Benedikt argued that once people start using IPv6 as much as IPv4, then he felt we would probably see that increase.

Marco Hogewoning directed both Benedikt and the attendee to continue their discussion on the mailing list.

Mikael Abrahammson, T-Systems, commented that he had been doing the same thing as Benedikt for a couple of years with two uplinks, and that it works really well. He commented that they need something automatic to make it work, which is basically an IPv6 tunnel broker. He commented that they could have it as a third party as well, and it could be anyone. He added that he would also like to see end hosts partaking in multipath TCP or SHIM6, and stated that he felt this is the way they need to go, long-term, to work without cludges.

Benedikt responded that he wasn’t sure, and we will see about SHIM 6. He conceded that it’s a problem with the locator identifier.

Mikael replied that the only way this will scale long-term is with a kind of mechanism where the end-host has multiple addresses for ISPs and can then choose.

Gert Doering, SpaceNet AG, added that they have discussed this, but for the sake of the audience he was bringing about another point of view: it would work and it’s good to save some global routing slots, so there is a definite benefit to this method. He then stated that he thinks it’s overdoing it, because what you gain from it is session survivability if one of the ISPs goes down. He stated that he has been convinced that most sessions, for the standard end users as opposed to the people in the room, are so short that, if an ISP goes down, they just click reload in their browser and the problem is solved. He therefore thinks the market for something so complex is small; however, at the same time, we need to be working on teaching applications to handle multiple sources better, and to handle the failure of a single source address better. He added that this is “dark matter” at the IETF he noted that this is not specified at all.

Marco commented that when he asked Benedikt the question that helped inspire the presentation, he was commenting about small or medium-sized business becoming redundant, as opposed to end users. However, he noted that if you fit your house with sensors, it may become beneficial to run this at a Homenet.

Benedikt added that Marco’s concern was that, in some countries where there is a national firewall, for example, maintaining a session may be helpful.

There were no further questions.

G. IPv6 Source Address, What Could Possibly Go Wrong? - Jen Linkova, Google

The presentation is available online at: https://ripe67.ripe.net/presentations/288-Jen_RIPE67.pdf

Marco Hogewoning asked whether, on the site local, Jen thinks this is because it’s deprecated, or old installations, or old books.

Jen responded that some people probably chose them being unaware of them becoming deprecated, while looking for private addresses for IPv6, and did not pay enough attention to the differences between UL and site local. On her site local slides, she sees plenty of ICMP packets and stated that maybe some people were using them for infrastructure links – and maybe there are some other explanations.

Marco commented that it may be useful for those doing IPv6 training to spend more time on this.

Benedikt Stockebrand stated that he may have some explanation for some of the “weird” stuff. He stated that people have taken him aside and told him they have added IPv6 support as far as they could, but never got a chance to test it (due to managerial constraints). Therefore, Benedikt believes that maybe there’s a chance some software out there was only tested with IPv4 but that developers tried to implement IPv6 within it – but could never test it properly. Benedikt stated that it may be interesting to see if the “weird stuff” changes in the future.

Jen agreed that she could check the numbers, compare the two years and look at the difference.

Benedikt commented that it would perhaps be interesting because he thinks there are more people who tried to make IPv6 functional when they didn’t know what they were doing and the software is therefore out there, but for IPv4 only.

Marco wondered whether it would be worth cooperating with the MAT Working Group and expand this type of measurement into something more long-running.

Jen stated that she would have a discussion with Google’s security group because she basically did firewall filtering and just collected everything.

Marco added that it may be worth looking at different pick-up points other than google.com and that it would be interesting to see how it changes over time.

There were no further questions.

H. Moving on…IPv6, DS-Lite and PCP Anastasios Chatzithomaoglou, Forthnet

The presentation is available online at: https://ripe67.ripe.net/presentations/287-Tassos_Chatzithomaoglou_-_Moving_On..._IPv6,_DS-Lite_&_PCP_-_17.10.2013.pdf

Rumy Kanis, RIPE NCC, asked a question as chat monitor on behalf of an unnamed participant. The participant asked whether Tassos had experienced any issues with path MTU discovery on IPv4 when they run it over DS-Lite.

Tassos responded that they had a lot of issues until they solved it with IPv4 and the CPE initially when they started testing. That was one year ago, it was resolved and then every CPE that tested had their own MTU so they had a lot of issues there. The issues were resolved.

Rumy asked a combined question from Ole Troan, IETF, and Mark Townsley, Cisco, via the chat room. They didn’t understand why DS-Lite was cheaper than NAT 444, both having centralised CGN with a similar amount of state, and wondered whether Tassos had calculated the cost of moving the net state to the CPE, as in running “A plus B”.

Tassos responded that they hadn’t calculated that until now, but were evaluating that. He continued that, as IPv6 traffic increases, they have lower traffic from the CGN, so instead of having the whole subscriber traffic passing through the CGN in the 444 solution, they only pass the actual IPv4 traffic. So in the future, when they reach 50% of IPv6 traffic, the CGN load will only be 50% because half the traffic will be outside the CGN. It will become cheaper over time.

Rumy commented that it is the same as with dual stack.

Tassos agreed, but noted that they don’t have any cost on the dual stack side.

There were no further questions.

I. Exchange of Feedback on Running an IPv6 Only LAN at the RIPE Meeting - Marco Hogewoning, IPv6 Working Group Chair and Andrew Yourtchenko, Cisco

The presentation is available at: https://ripe67.ripe.net/presentations/129-IPv6-WG-2.pdf

Marco Hogewoning began, stating that it was RIPE 37 in September 2000 when the first IPv6 network was available at a RIPE Meeting. He said he and Andrew felt it was time for the next step – running an IPv6-only network. He emphasised that it was not supported by the RIPE NCC technical team, was a voluntary effort, and done on a best-effort basis.

Marco proceeded to thank Cisco for their gear and manpower, and Andrew Yourtchenko specifically. Marco acknowledged that while the RIPE NCC technical team didn’t officially support the endeavor, they did put in effort to ensure that the network was running, and thanked the team.

Marco stated that they had a “wholesale” model – the RIPE NCC provided them with an SSID that was running on the normal frequency map, and delivered all the traffic to them, where they pumped it into a Cisco AS RIK, which they borrowed, and had an uplink to the RIPE Juniper in between. The uplink to the Juniper was dual stacked, the site towards the wireless was entirely IPv6 only, and since they were running Net 64, they also needed the DNS server. They bought a server in the form of an old Macbook running virtual servers, and that was all dual stacked. He said it was a simple setup, all wires, and no VLANs or anything else to complicate matters.

Marco explained that it was switched on Sunday, and they slowly made it work. Traffic was not particularly large apart from one big spike of 24 megabits. He said the number of clients was somewhat small, but on Tuesday afternoon they saw between 30 and 50 clients online all the time. Marco added that he is aware that the average number of devices at RIPE Meetings is about 700, so he thinks approximately 5% of the attendees at the session had tried it.

As far as incidents are concerned, he said there was one failure on Monday afternoon, after the IPv6-only network was announced in the plenary. A faulty patch cable fell out of the laptop server, and without DNS etc., everything shut down. Andrew rushed up to repair it.

Other than that, they attempted imprecise network monitoring. Twitter was busy, using NAT 64. There was a hashtag which invoked a lot of response, and the operators of the IPv6-only network were grateful for the feedback. Facebook supported IPv6 on the website, but didn’t on their apps. They also tried using the mailing list, and discovered that if you have an iPad, you couldn’t get your mail over an IPv6-only network.

Some feedback was that users encountered a failure called IP 101 when trying to reset a Cisco password.

Andrew Yourtchenko took the floor, stating that this is not specific to IPv6-only, and is the reason why people should enable IPv6 on the website now rather than later. It had slipped past the testing as they were dual stacking a bunch of back-end servers a month or so ago, and the percentage of users is relatively low. They discovered it after all the paperwork had been completed and everything had been “lit up” so they decided to keep IPv6 on the server in spite of this. He said the good news is that they are working on this, and hopefully would have more news the next day.

Regarding DNS issues, a lot of people use the operating systems that don’t support getting DNS, either by stateless DHVP v4, or RA. He said manual configuration was needed, which is awkward with IPv6 addresses.

He had conducted a speed test on Sunday, and IPv4 over IPv6 still came out faster than IPv6. He said the good news was that it was isolated to a specific server (in the Netherlands), but Andrew thinks there is still work to do there.

Andrew commented, regarding Aerohive Manager, that there were many “unknown operating systems” detected. The detection mechanisms in the management systems, therefore, still need to catch up. He said the interesting thing was that the number of clients when measured as a sum of 2.4 and 5 Ghz clients is bigger than the number of clients as measured by the operating system detection, and this should normally be the same number. There are clients by operating system, and clients by radio – and when it doesn’t add up, some clients are in “limbo”. Andrew believed that these are probably the people who switched off IPv4 completely and then the management doesn’t know how to deal with it.

Andrew asked the attendees how many people used only IPv6 during this conference. After a show of hands, he concluded that it was around the 30 addresses that they saw in the conference. He thanked those using it. He invited the attendees to give feedback, and asked whether they would try this in their own networks.

Patrick Falstrom, Netnod, commented that he was running the wireless network at a social media conference in Sweden, attended by people who were not particularly technically minded. Even so, Patrick ran an IPv6-only network and it was still very interesting, and attendees were very appreciative. He commented that Twitter didn’t have a good IPv6 experience. He felt it was particularly interesting to run this in an environment where people did not know much about IPv6 or networking.

Jen Linkova, Google, thanked Marco and Andrew, commenting that it was a very interesting experience that should definitely be repeated. She switched to IPv4 twice – to change her Cisco password, and to change the VPN. However, she stated that she used IPv6 most of the time and it’s good that all applications could be tested, besides Facebook and Twitter.

Marco stated that the RIPE NCC corporate VPN became unstable while working over the IPv6-only network, so he switched back to the regular network in order to keep accessing emails.

Gert Doering, SpaceNet AG, spoke up that it was not the first time an IPv6-only had been attempted , and that it had been enacted in Berlin with great success, so it should be a regular service for every RIPE Meeting.

Marco commented that he would relay this to the meeting organisation team to see what they could do. However, he recalled that in Berlin the network went down.

Gert acknowledged that it worked much better this time than it had in Berlin, and commended Marco and Andrew on a job well done. He referred to Berlin as an experiment, stating that now they know how to run it.

An unnamed attendee remarked about the Net 64 prefix. He asked why the documentation prefix was used.

Andrew responded, attributing this simply to laziness. He said he used the well-known prefix in some cases, where the addresses were RFC 1918. The standard prohibits the use of the well-known prefix, so, in that instance, he quickly hacked into something else.

The speaker responded that it was about time the recommendation gets sent to Google.

Andrew responded that it doesn’t get sent.

Marco asked which of the attendees had discovered something that didn’t work and fixed it. He noted one attendee raising their hand. Marco stated that part of the purpose of this experiment was to find out what doesn’t work and fix it.

David Kessens, IPv6 Working Group co-Chair, closed the session, thanking the attendees and inviting them to spend time on the IPv6-only network. Marco added, as a concluding comment, that everything related to IPv6 is welcome on the IPv6 Working Group Mailing List, not just policy-related issues.