November 2012 - ipv6-wg - mailman.ripe.net

Minutes of RIPE 65
by MarcoH 04 Jan '13

04 Jan '13

Dear working group members, Thank you all for participating in our last gathering during RIPE 65 in Amsterdam. The archives have been published on the website, in case you missed something. Attached are the minutes of our sessions. Many thanks to the RIPE NCC staff for making them. If you have any additions or corrections, please reply to this email before November 28th, 23:59 UTC. If no comments are made, we will declare these final and ask the RIPE NCC to publish them. In the meantime we have started preparing for RIPE 66, which will take place in Dublin from 13-17 May 2013. If you are busy deploying IPv6 or maybe if you don't, please contribute by sharing your experiences. Respond to the Call for Papers as published on http://ripe66.ripe.net. Or if you want some time in our working group, contact us at ipv6-wg-chair at ripe dot net. Thank you, Marco, David and Shane ====================================================================================== RIPE 65 IPv6 Working Group Date: Session I - 26 September 2012, 14:00 - 15:30, Session II - Thursday, 27 September 2012, 09:00 – 10:30 Scribe: Alex Band (Session I), Matt Parker (Session II) WG chairs: David Kessens, Shane Kerr, Marco Hogewoning 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 is was easier said than done. Mark Townsley, Cisco, 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 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 network 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 sareplied that 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.2… 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 on another project. Anastasios responded that they would have considered that if they had more time. 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_RI… 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.… 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 B was to give an alternative to evil, fat, big stateful CGN.MAP is a stateless version of A plus B 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_Su… 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

1 1

RIPE NCC Webinars - new dates
by Training Mailbox 21 Dec '12

21 Dec '12

[Apologies for duplicate e-mails] Dear colleagues, We are pleased to announce the launch of new dates for our Webinars for LIRs. The RIPE NCC Webinars are live, one hour online training courses that allow participants to interact with our trainers without leaving their desks. We focus on the topics and issues most important for LIRs. Register now at https://www.ripe.net/lir-services/training/e-learning/webinars Participation is limited to 20 people, so don't hesitate if you want to take part! If you have questions, please email <e-learning(a)ripe.net>. We look forward to seeing you online. Kind regards, RIPE NCC Training Services

1 1

MERIT Darknet Experiment and RPKI alerts
by Alex Band 10 Dec '12

10 Dec '12

A number of you have reported that your are getting alert emails from the Resource Certification (RPKI) service. The alerting system can warn you if some of your certified address space has the RPKI validity "Unknown" or "Invalid". The warning people are receiving will look something like this: > There are alerts about BGP announcements with your certified address > space in the Resource Certification (RPKI) service. > > These are BGP announcements with your certified address space that have > the status Unknown. You should create a ROA for each authorised > announcement to make them Valid: > > AS Number Prefix > AS237 2a00::/12 > > You are able to fix and ignore reported issues, change your alert > settings, or unsubscribe by visiting http://certification.ripe.net/. In this case, the alert is triggered for LIRs who hold an IPv6 address block, but do not announce (all of) it. The *unannounced* address space is being "hijacked" by MERIT as part of its darknet experiment: http://www.ripe.net/internet-coordination/news/merit-to-temporarily-use-2a0… If you have received the alert, your certified, unannounced IPv6 prefix is hijacked by AS237 because 2a00::/12 is the most specific announcement that overlaps with it. There are two things you can do: 1. Announce *all* of the IPv6 address space you hold. This way AS237 cannot hijack your prefix with a less specific announcement. 2. Suppress the alert for the announcement from AS237 in the Resource Certification (RPKI) system in the LIR Portal. Please note that the RPKI Alerting system uses the RIPE NCC Route Collectors to trigger the errors, so there may be slight differences between what they see and what you actually do. If you have any questions, please do not hesitate to contact me. Kind regards, Alex Band

8 10

RIPE NCC Training Courses January-March 2013 - BG, DE, UK, PT, NL, SA, DK, UA, LV, KG
by Training Mailbox 26 Nov '12

26 Nov '12

Dear Colleagues, Our training team travels the RIPE NCC service region to deliver training courses to our members without any additional cost. Over the next few months, we'll be in Sofia, Düsseldorf, London, Lisbon, Milan, Amsterdam, Riyadh, Copenhagen, Kiev, Riga, Bishkek. Visit the following page to register and to check which training courses we are giving in your area: https://lirportal.ripe.net/training/courses The RIPE NCC delivers the following training courses: - LIR Training Course - IPv6 for LIRs Training Course - Routing Registry and Resource Certification Training Course For more information visit: http://www.ripe.net/lir-services/training/courses With kind regards, Rumy Spratley-Kanis Training Services Manager

1 0

IP Analyser IPv6 functionality
by Alex Band 05 Nov '12

05 Nov '12

A few weeks ago the RIPE NCC introduced the production release of the IP Analyser; an LIR Portal tool to help you manage and analyse your allocations, assignments, free space and invalids: https://lirportal.ripe.net/ipanalyser/ (requires member login) Currently it only provides IPv4 functionality and we are in the process of gathering IPv6 feature requirements so we can plan a roadmap for the beginning of 2013. This is why I would like to know what kind of functionally you would like the IP Analyser to provide. I'm looking for input for invalid or incorrect DB assignments, and tools to make your IP address management easier. As warnings, the application could for example display all RIPE DB objects which have an incorrect prefix length; a sanity checker basically. So if you created an inetnum or route object with prefix "2001:0DB8:0401::/40", the application would tell you that you probably meant to create "2001:0DB8:0400::/40". For tools, the IP Analyser currently suggests prefixes out of your free IPv4 allocations for assignments, but this is not very useful in IPv6 (i.e. please suggest me a free /48 out of my /32). You would probably benefit more from a subnet calculator, an address notation validator or something else entirely. I'm looking forward to your input. Cheers, Alex Band Product Manager RIPE NCC

1 0

Re: [ipv6-wg] route6: 2A00::/12
by Antonio Prado 01 Nov '12

01 Nov '12

[cross-posted to ipv6-wg(a)ripe.net] Il 20/10/12 21:58, Manish Karir ha scritto: > > Hi Antonio, > > Yes. Merit is in the process of running a large IPv6 darknet experiment. Our goal is to announce every allocated /12 (1 from each RIR) first sequentially and then together. We conducted a 1hr test announcement on wed and to the best of knowledge we did not break anything. > These announcements will each last 1 week each starting Nov 1. > Your more specific announcements in BGP should still get all your data correctly routed to you. However if you have noticed any strange behavior please let us know. > > Thanks. > -manish Manish, thanks for your kind reply. Maybe I missed some announcement e-mail here. Is there any document to read about that "large IPv6 darknet experiment" you at Merit are going to run in accordance also with RIPE NCC? (I'm aware of what Geoff Juston made at APINIC in June 2010 with 2400::/12 https://labs.ripe.net/Members/mirjam/background-radiation-in-ipv6) I was wondering if any consensus is needed before starting such a big thing that involves IPv6 production networks as well. I mean: when my route6 is not announced via BGP, it's supposed that every packet sent to it doesn't get anywhere, hopefully. OTOH, if during this experiment, for any reason (wanted or not), my prefix is no more announced, I'm afraid the /12 would attract (perhaps hijack?) those packets (actually breaking, I believe, any existent ROA for the prefix). So, just asking: what kind of packets are going to be collected and how stored, analysed and by whom? Thank you -- antonio > ----- Original Message ----- > From: Antonio Prado <aprado(a)topnet.it> > To: ipv6-ops(a)lists.cluenet.de > Cc: mkarir(a)merit.edu > Sent: Fri, 19 Oct 2012 13:09:23 -0400 (EDT) > Subject: route6: 2A00::/12 > > Hello, > > just saw a new entry in RADB for 2A00::/12 and was wondering if could be > a fat-finger issue as our IPv6 prefix (a /29) actually belongs to that /12. > > route6: 2A00::/12 > descr: MERIT Network Inc. > 1000 Oakbrook Drive, Suite 200 > Ann Arbor > MI 48104, USA > origin: AS237 > mnt-by: MAINT-AS237 > remarks: This announcement is part of an RIPE approved > experiment. For additional information please > send email to mkarir(a)merit.edu > source: RADB > changed: ljb(a)merit.edu 20121017 > > Anyone aware of this experiment? > > Thank you > -- > antonio >

6 9