Dear colleagues, Attached are the draft minutes of our working group session in Vienna at the RIPE63 Meeting. Please review them and if you have any corrections or comments, please post them to this list before Friday the 27th of January COB. If we haven't received any comments or corrections by that date, we will assume consensus and will ask the RIPE NCC to publish these as final. Again many thanks to the RIPE NCC for their support in scribing the session. Marco Hogewoning RIPE 63 Scribe: Mirjam Kuehne WG chairs: David Kessens, Shane Kerr, Marco Hogewoning Date: 1 November 2011, 16:00 - 17:30 IPv6 WG meeting (first session) Marco Hogewoning opens the IPv6-WG 1. Administrivia: - Minutes of RIPE 61 have been circulated - There was no IPv6-WG session at RIPE 62 - Thanks to the RIPE NCC for taking minutes at RIPE 63 2. Renumbering IPv6 - IETF 6RENUM WG (Tim Chown, Wes George; presented by Shane Kerr) The Address Policy WG asked the IPv6-WG for some advice about renumbering. Trying to avoid renumbering could be a reason for organisations to request PI space. Renumbering is considered to be difficult. But if renumbering would be very easy, then this wouldn't be a good reason for PI space (there might be others however). The IETF 6RENUM WG is working on this topic. It was formed after a BoF at IETF 81. There was some previous work done on IPv6 renumbering (see RFC 4192, RFC 5887 and draft-chown-v6ops-renumber-thinkabout-05). The current work of the 6RENUM WG is focused on renumbering for enterprise networks, not ISP networks. But enterprises all get their Internet connectivity from somewhere - from ISPs. Many of them are in the RIPE community. Tim Chown is looking for feedback from this community. The first 6RENUM WG draft documents internal triggers to renumber. There is also a document providing a gap analysis. Q&A: James Blessing commented that IF you design your network properly in the first place, renumbering is fairly straightforward - it is still work, but it's straightforward. Marco was wondering if it would help if this group would come up with a BCP about network design. Shane thought this would be a good idea (people usually appreciate RIPE BCPs). Gert Doering (Spacenet and IPv6 user for many years) agreed with James: A large part of the pain can be avoided with a good network design. Don't hardcode IP addresses etc. A BCP document listing the dos and don'ts would be useful. On the other hand, we don't want to overlap with the IETF WG (would have to check that this is not part of their charter). Marco emphasised that the IETF 6RENUM WG is mostly focused on enterprise networks. He suggested that the RIPE IPv6-WG could fill the gap and provide some documentation for ISPs. Gert said he obviously thought about this also, because it is related to address policy. Gert said he spent some thought on that as well, because obviously touches on Address Policy. Like I if he’s a small ISP and not multi‑homed yet but wants independent addresses and why not just renumber if you change upstream and? One of the really painful things about renumbering an ISP network is you have to renumber your customers and that works for end users that are fully automated provisioned, like prefix delegation and stuff so there is no boxes to be touched and the box auto configures everything on connection anyway but it doesn't work at all for business ISPs where you have many configured firewalls and everything, so renumbering an ISP with business customers is nearly impossible. Gert said he’s done it two times and that it's nearly impossible. So this might be the reason why they have excluded ISPs from this scope. On the other hand, some parts of the ISPs are just an enterprise network, like server housing, DNS servers, firewalls and stuff, so there is overlap again. Shane said there was a couple of different things going on, one being able to provide recommendations to people who are doing network design, maybe even in the case where you have customers perhaps recommending prefix delegation or whatever. But the other issue is the recommendations on the policy space, maybe clarifying in which cases PI space makes sense, for instance a small ISP with downstream customers or something like that. Gert said that better defining the problem space, would certainly help making appropriate policy. Documenting different use cases could be helpful. James commented that according to current policy, having PI IPv6 address space stops you from giving addresses to customers. Gert said that this is correct and that it's an artefact of the history of PI address space policy. This will be discussed more in the Address Policy WG. Maksym Tulyuk (AMS-IX) reported that at AMS-IX they renumbered from PI to PA IPv6 space and that this was not a big problem. Marco clarified that this was a migration of a service network, not a customer network. Benedikt Stockebrand said that when it comes to renumbering, the biggest problem is all the legacy equipment and configurations. You need to figure out first what the network is supposed to be doing before you renumber it. Shane asked the audience if IPv6 provides any benefits at all when it comes to renumbering? Benedikt said it is important that people realise how to pay for this in the long run. Aaron Hughes (6connect) reported that in the ARIN region, a best current operational practices track was started. The first document described subnetting IPv6 for ISPs. We also said that they'd be happy to work on documentation for enterprises as well. These topics are discussed on the following mailing list: bcp-discuss at bind.com <mailto:bcp-discuss at bind.com
Aaron said he’d send more information to the RIPE IPv6-WG mailing list. Jan Zorz wondered why the IETF created the 6RENUM WG. Shane responded that it might be a little early to present their work since the WG has just started. Gert responded to Shane's earlier question that renumbering in IPv6 is easier, because all stacks know how to handle multiple addresses at the same time. But from a planning point of view, it is the same. ACTION WG chair: to send mail to the mailing list asking if there are volunteers to start on a renumbering BCP for ISPs and if people know if there is already work being done in this area. 3. Replacing ripe-501 (Jan Zorz, Sander Steffann) See "Requirements for IPv6 in ICT Equipment": http://www.ripe.net/ripe/docs/ripe-501 ripe-501 was published a year ago and has already been translated into ten languages.Since then many requests for changes were received. The document was a great success, but of course things can always be improved. New devices were added to the document. Specifications about load balancers were added. The compliance criteria were also simplified. There was a good discussion on the mailing list. The document is currently in last call. Note that the document is meant as a template, don't just cut and paste bits and pieces. Jan and Sander thanked Merike Kaeo for providing a lot of useful input. Randy Bush (IIJ) had a question about the CPE diagram in the document. Jan explained that the RFC written by Ole Troan was included as a mandatory requirement. The idea was not to duplicate Ole's work. If a CPE does not support this RFC, it should not be taken into account in the process. Sander asked people to send comments to the mailing lists to specify if this comment should be included right now (which means extending the last call) or if it is OK to include it in the next version. The Last Call for the current version of the document ends next week, 10 November 2011. Tahar Schaa (consultant supporting German government) asked what their plans were to include source address validation improvements. Sander confirmed that it would be included in the document. But it is up to the tender initiator to ask for this requirement or not. 4. Horses for courses - like IPv6 profiles for German Administration (Constanze Buerger, Bundesministerium des Inneren, Germany) The prepsentation is available at: http://ripe63.ripe.net/presentations/74-2011_RIPE_63_de.government_Constanze... Maksym asked if the files Constanze mentioned in her presentation are publicly available. Constance said this has not yet been decided. Alexander Isavnin from Russia wondered how much this process is costing the German taxpayers? Constance responded that they are just coordinating the IPv6 address space allocated to them and the deployment to all federal governments and institutions. But it will take a long time until this is finished. Alexander asked if each department has its own budget. Constance confirmed that this is the case. She also explained that it is not so easy to convince people to cooperate. Every municipality can do their own thing. That means she and her team have to do a lot of convincing, but they cannot force the others to cooperate. Jan Zorz thanked Constanze for considering ripe-501 as a basis for her work and mentioned that there will be a new version (and a new number). He asked that Constanze and Tahar make their own adjustments in their documentation when the new version comes out. Tahar clarified that ripe-501 goes into the same direction as their work is going already anyway. So yes, a few adjustments will have to be made, but it's not that difficult, because they are aware of the changes. Jan asked if Constanze or Tahar are aware of any other governments following the German example. Tahar said he believed that Spain is following a similar process. Martin Levy (Hurricane Electric) thought it would be better to rephrase the earlier question: “What would this cost if you were to ignore IPv6?”. Constance explained that they tried to analyse the costs so that they can put some pressure on the leadership. But it turned out to be very difficult, because the government and the network is so heterogeneous. In the end they had to stop the process analysing the costs. Tahar added that Germany, due to its constitution, is a complex country. The costs are held and managed in each state and each municipality. All that can be done really is to provide the first steps and some supporting documentation. He saw two main motivations to deploy IPv6: 1. Address renumbering (there is a long history of using IPv4 address, mostly private, which means that there is now a horrible network of cascading NAT layers. Some of the networks have been renumbered up to four times and this is very costly. Deploying IPv6 will solve these problems. 2. If one wants to set up a telephone infrastructure in Germany today, it is only possible to buy VoIP telephony. What about one office wants to call another and the addresses clash? You can better start using public (IPv6) addresses. In conclusion, the question is not: What does it cost to do it, but what does it cost not to do it? Constance said yes, just do it. 4. Status of ADSL Deployment in the XS4All network (Timo Hilbrink, XS4All) The presentation is available at: http://ripe63.ripe.net/presentations/75-th-ipv6-ripe63-20111101.pdf Maksym asked why the MTU on one of the slides was set to 1452, why it was so low and whether it was part of his implementation. Timo said yes. Gert applaud Timo and XS4All on this. He said it was great to see one mass-market provider go forward with this. He said he hopes that there will also be more users in Germany any time soon. Andy Davidson (Hurricane Electric) asked if Timo knew the retail prices of the new CPEs that include IPv6. Timo said they were around EUR 100. Andy concluded that that price is coming down all the time, which is great. 5. Lightning Talks 5.1. Results of the 2011 Global IPv6 Deployment Monitoring Survey (Chris Buckridge for Maarten Botemann) The presentation is available at: http://ripe63.ripe.net/presentations/114-ipv6-survey-BUCKRIDGE.pdf 5.2. Effects of Capacity Building on IPv6 Adoption and Deployment (Marco Hogewoning, RIPE NCC) The presentation is available at: http://ripe63.ripe.net/presentations/66-MH-RIPE63-Capacity-LT.pdf 5.3. Stateless IPv4 over IPv6 in 5 minutes (Ole Troan, Cisco) The presentation is available at: http://ripe63.ripe.net/presentations/40-RIPE63-MAP-lightning.pdf Jan, as a member of the MAP (A+P) architecture team, asked attendees if they felt that well-known ports must never be allocated to a user or if the user should have the opportunity to use well-known ports. Ole responded that you could give users that are not happy with the default setting a full IPv4 address. Benedikt explained that users shouldn't need low ports. He wondered if prolonging IPv4 is really worth the effort. The majority of people don't want to run a server at home. For those who want to, they will switch to IPv6 shortly. Those who use an IPv4 server at home will get some IPv4 addresses from somewhere. It's not something you want to provision for mass customer products. Jan said he believed stateless A+P is worthwhile because we don't want CGNs. Benedikt disagreed and said he wants CGN and wants it to hurt that much that people will use native IPv6 in the end. Jari Arkko (Eriksson) pointed out that there are trade-offs: If you are doing port division per customer on an static basis for customers, the power user and a small user get the same service, which neither of them will be happy with; we will pay in any case. 6. IANA Reserved IPv4 prefixes for shared CGN space (David Kessens) The presentation is available at: http://ripe63.ripe.net/presentations/84-201111012011-ripe63-vienna-sharedadd... < http://ripe63.ripe.net/presentations/84-201111012011-ripe63-vienna-sharedadd...
Gert wondered which address space they were going to use. David agreed that this is of course an issue. However, since this proposal was well received in the ARIN region, it was suggested to use a /10 out of ARINs' address space. Jari reported that he was one of the IESG members who reviewed this document and said he had a couple of concerns. Apart from the policy issues that are down to the RIR communities to decide, there are some issues with this particular proposal. What's the affect on the ISP ("My device works well now, but does it have negative affects on other parts of the network?"). He urged people to participate in this discussion and check if this would break anything. Kurtis Lindquist commented that this whole process seemed a little weird (between one RIR and the IAB and the IESG). Martin Levy said it is interesting that they were talking about IPv4 and CGNs a lot instead of about IPv6. ACTION: It was decided to defer the topic of draft-weil-shared-transition-space-request to the mailing list. 7. IPv6 Speed Dating Marco asked the audience how many people in the room have deployed IPv6 (about half of the room). The other half is busy deploying it. He further asked those who are busy deploying it, what the biggest challenge is they face in the process? A speaker from the audience said that the biggest challenge is to convince the management. The management thinks it is too expensive. Marco asked those who deployed IPv6 how they passed that hurdle. Andy said to just do it anyways. Jan Zorz responded that he gave a 45 minute presentation earlier explaining how to convince the management. Benedikt suggested to ask the management: "What's the business case of an earth quake?" The same applies to IPv6: by trying to safe money, you might lose customers and money in the end. Timo suggested to explain to the management what they would lose if they didn't do it. Jen Linkova (Google) explained that from an operational perspective they are still discovering bugs now and that they have to test almost everything again for IPv6. Therefore her advice is to test everything twice from the start, don't expect things to works out of the box. Marco pointed out that this community and especially this IPv6 WG is a great pool of resources on IPv6 deployment. Dave Wilson (HEAnet) responded to the question of what problem he had to solve and how he convinced his boss. He said he solved this in his case by providing a business case. But that might be different in other environments. A speaker from the audience said that after convincing your boss, the main problem is organisational: all departments in your company (networks, IT, service, marketing etc.) have to work together. That is not always easy. Andy added to his earlier comment that even if people don't have official mandate, he would advise them to skill-up anyways, so they can be prepared for the deployment phase. The working group co-chairs thanked attendees and closed the session. Summary of Action Points – IPv6 WG RIPE 63 ACTION WG chair: to send mail to the mailing list asking if there are volunteers to start on a renumbering BCP for ISPs and if people know if there is already work being done in this area. ACTION: It was decided to defer the topic of draft-weil-shared-transition-space-request to the mailing list.