From mir at ripe.net Thu Nov 1 16:44:01 2012 From: mir at ripe.net (Mirjam Kuehne) Date: Thu, 01 Nov 2012 16:44:01 +0100 Subject: [ipv6-wg] route6: 2A00::/12 In-Reply-To: References: <995988419.1420427.1350763118928.JavaMail.root@merit.edu> <5083CC93.1070002@topnet.it> Message-ID: <509298C1.6080703@ripe.net> Hi, Just to confirm: The RIPE NCC is aware of this and has authorised MERIT to use the address space for this purpose. You can find some more details on RIPE Labs: https://labs.ripe.net/Members/mirjam/ipv6-darknet-experiment The results will also be published on RIPE Labs. Kind regards, Mirjam Kuehne RIPE NCC On 21/10/12 6:17 PM, Manish Karir wrote: > > Hi Antonio, > > Here is some related material: > > Internet Pollution Studies in IPv4: > > - 1/8 Pollution NANOG Presentation: http://www.merit.edu/research/pdf/2010/karir_1slash8.pdf > > - Follow on: NANOG Presentation: http://www.merit.edu/research/pdf/2011/Internet-Pollution-Part2.pdf > > - IMC Paper on Internet Pollution: http://www.merit.edu/research/pdf/2010/imc10-wustrow.pdf > > A recent workshop on the topic: http://www.caida.org/workshops/dust/1205/ > > Internet Pollution in IPv6: > > - Geoff Hustons work on IPv6 darknets: http://www.caida.org/workshops/dust/1205/slides/dust1205_ghuston.pdf > > - Details of APNICs experiment with announcing their IPv6 cover /12 route as well as analysis of results: http://www.caida.org/workshops/dust/1205/slides/dust1205_cdeccio.pdf > > This particular effort is an attempt to replicate the work performed by Geoff Huston at APNIC for different regions in order to understand any regional > variations that might exist. > In general we collect all un-wanted traffic in the darknet of our experiment. Our general experiment architecture is shown here: http://software.merit.edu/darknet > Results from our analysis are presented back into the Internet operations community along with any recommendations that might emerge. Data collected is shared > with researchers at the RIRs for their own analysis. > > Please let me know if you have additional questions. > > Thanks. > -manish > > > > > > On Oct 21, 2012, at 6:21 AM, Antonio Prado wrote: > >> [cross-posted to ipv6-wg at 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 >>> To: ipv6-ops at lists.cluenet.de >>> Cc: mkarir at 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 at merit.edu >>> source: RADB >>> changed: ljb at merit.edu 20121017 >>> >>> Anyone aware of this experiment? >>> >>> Thank you >>> -- >>> antonio >>> >> > > From aprado at topnet.it Thu Nov 1 17:00:31 2012 From: aprado at topnet.it (Antonio Prado) Date: Thu, 01 Nov 2012 17:00:31 +0100 Subject: [ipv6-wg] route6: 2A00::/12 In-Reply-To: <509298C1.6080703@ripe.net> References: <995988419.1420427.1350763118928.JavaMail.root@merit.edu> <5083CC93.1070002@topnet.it> <509298C1.6080703@ripe.net> Message-ID: <50929C9F.5000109@topnet.it> On 11/1/12 4:44 PM, Mirjam Kuehne wrote: > Hi, > > Just to confirm: The RIPE NCC is aware of this and has authorised MERIT > to use the address space for this purpose. You can find some more > details on RIPE Labs: > > https://labs.ripe.net/Members/mirjam/ipv6-darknet-experiment Hi, on Merit website has appeared a comprehensive page, with Letters of authority as well: http://software.merit.edu/darknetv6/ Thanks -- antonio From alexb at ripe.net Mon Nov 5 10:04:50 2012 From: alexb at ripe.net (Alex Band) Date: Mon, 5 Nov 2012 10:04:50 +0100 Subject: [ipv6-wg] IP Analyser IPv6 functionality Message-ID: <8EA2CE0C-7741-4033-B6E8-BAC54ECDD21C@ripe.net> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2355 bytes Desc: not available URL: From alexb at ripe.net Fri Nov 9 10:33:24 2012 From: alexb at ripe.net (Alex Band) Date: Fri, 9 Nov 2012 10:33:24 +0100 Subject: [ipv6-wg] MERIT Darknet Experiment and RPKI alerts Message-ID: <8380CB55-4728-4866-AC91-7FF3EC5444BC@ripe.net> 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-2a00-0000-12-for-darknet-experiment 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2355 bytes Desc: not available URL: From aprado at topnet.it Fri Nov 9 12:00:37 2012 From: aprado at topnet.it (Antonio Prado) Date: Fri, 09 Nov 2012 12:00:37 +0100 Subject: [ipv6-wg] MERIT Darknet Experiment and RPKI alerts In-Reply-To: <8380CB55-4728-4866-AC91-7FF3EC5444BC@ripe.net> References: <8380CB55-4728-4866-AC91-7FF3EC5444BC@ripe.net> Message-ID: <509CE255.6050301@topnet.it> On 11/9/12 10:33 AM, Alex Band wrote: > 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: Hi Alex, thank you for your advice. Anyway, this behavior was easily foretold in a previous message posted on the list ipv6-wg about 20 days ago. Thanks -- antonio From Woeber at CC.UniVie.ac.at Fri Nov 9 12:05:04 2012 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Fri, 09 Nov 2012 12:05:04 +0100 Subject: [ipv6-wg] [routing-wg] MERIT Darknet Experiment and RPKI alerts In-Reply-To: <8380CB55-4728-4866-AC91-7FF3EC5444BC@ripe.net> References: <8380CB55-4728-4866-AC91-7FF3EC5444BC@ripe.net> Message-ID: <509CE360.8010109@CC.UniVie.ac.at> Overall, I think this is very dangerous approach, and the wrong way to start with. There might be very good reasons, why a full block of (IPv6) addresses, or a subset of, ist not (yet) globally visible. Announcing/Hijacking those addresses may seriously interfere with local tests or pilot deployment. IMHO this should be strictly opt-in, instead of opt-out! Wilfried. Alex Band wrote: > 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-2a00-0000-12-for-darknet-experiment > > 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 From daniel.karrenberg at ripe.net Tue Nov 13 09:36:39 2012 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 13 Nov 2012 09:36:39 +0100 Subject: [ipv6-wg] [routing-wg] MERIT Darknet Experiment and RPKI alerts In-Reply-To: <509CE360.8010109@CC.UniVie.ac.at> References: <8380CB55-4728-4866-AC91-7FF3EC5444BC@ripe.net> <509CE360.8010109@CC.UniVie.ac.at> Message-ID: <8BB6437E-6273-4733-BCAE-DD3F652B38C8@ripe.net> On 09.11.2012, at 12:05 , Wilfried Woeber wrote: > Overall, I think this is very dangerous approach, and the wrong way to start with. > > There might be very good reasons, why a full block of (IPv6) addresses, or a > subset of, ist not (yet) globally visible. Announcing/Hijacking those addresses > may seriously interfere with local tests or pilot deployment. > > IMHO this should be strictly opt-in, instead of opt-out! > > Wilfried. Wilfried, you are right. The agreement I thought we made with Merit was to use unallocated address space. Apparently a misunderstanding occurred somewhere along the way. We will talk to Merit and correct this. Daniel From shane at time-travellers.org Tue Nov 13 11:59:12 2012 From: shane at time-travellers.org (Shane Kerr) Date: Tue, 13 Nov 2012 11:59:12 +0100 Subject: [ipv6-wg] [routing-wg] MERIT Darknet Experiment and RPKI alerts In-Reply-To: <8BB6437E-6273-4733-BCAE-DD3F652B38C8@ripe.net> References: <8380CB55-4728-4866-AC91-7FF3EC5444BC@ripe.net> <509CE360.8010109@CC.UniVie.ac.at> <8BB6437E-6273-4733-BCAE-DD3F652B38C8@ripe.net> Message-ID: <20121113115912.4634ab63@shane-desktop> Daniel, On Tuesday, 2012-11-13 09:36:39 +0100, Daniel Karrenberg wrote: > > On 09.11.2012, at 12:05 , Wilfried Woeber wrote: > > > Overall, I think this is very dangerous approach, and the wrong way > > to start with. > > > > There might be very good reasons, why a full block of (IPv6) > > addresses, or a subset of, ist not (yet) globally visible. > > Announcing/Hijacking those addresses may seriously interfere with > > local tests or pilot deployment. > > > > IMHO this should be strictly opt-in, instead of opt-out! > > > > Wilfried. > > Wilfried, you are right. The agreement I thought we made with Merit > was to use unallocated address space. Apparently a misunderstanding > occurred somewhere along the way. We will talk to Merit and correct > this. Possibly such experiments should be announced in advance in the future, so that everyone can know what is going on. Ideally a pointer to a web page with full details about the experiment, but at least just a quick mail to the routing working group (and the IPv6 working group in cases where appropriate) seems reasonable. If this is something that requires a policy change I'd be happy to push it forward. Cheers, -- Shane From marcoh at marcoh.net Wed Nov 14 12:03:59 2012 From: marcoh at marcoh.net (MarcoH) Date: Wed, 14 Nov 2012 12:03:59 +0100 Subject: [ipv6-wg] Minutes of RIPE 65 Message-ID: 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.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 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_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 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_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 From training at ripe.net Mon Nov 19 09:40:20 2012 From: training at ripe.net (Training Mailbox) Date: Mon, 19 Nov 2012 09:40:20 +0100 Subject: [ipv6-wg] RIPE NCC Webinars - new dates Message-ID: <50A9F074.4000905@ripe.net> [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 . We look forward to seeing you online. Kind regards, RIPE NCC Training Services From daniel.karrenberg at ripe.net Fri Nov 23 00:36:46 2012 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 23 Nov 2012 00:36:46 +0100 Subject: [ipv6-wg] [routing-wg] MERIT Darknet Experiment and RPKI alerts In-Reply-To: <20121113115912.4634ab63@shane-desktop> References: <8380CB55-4728-4866-AC91-7FF3EC5444BC@ripe.net> <509CE360.8010109@CC.UniVie.ac.at> <8BB6437E-6273-4733-BCAE-DD3F652B38C8@ripe.net> <20121113115912.4634ab63@shane-desktop> Message-ID: On 13.11.2012, at 11:59 , Shane Kerr wrote: > Daniel, > > On Tuesday, 2012-11-13 09:36:39 +0100, > Daniel Karrenberg wrote: >> >> On 09.11.2012, at 12:05 , Wilfried Woeber wrote: >> >>> Overall, I think this is very dangerous approach, and the wrong way >>> to start with. >>> >>> There might be very good reasons, why a full block of (IPv6) >>> addresses, or a subset of, ist not (yet) globally visible. >>> Announcing/Hijacking those addresses may seriously interfere with >>> local tests or pilot deployment. >>> >>> IMHO this should be strictly opt-in, instead of opt-out! >>> >>> Wilfried. >> >> Wilfried, you are right. The agreement I thought we made with Merit >> was to use unallocated address space. Apparently a misunderstanding >> occurred somewhere along the way. We will talk to Merit and correct >> this. > > Possibly such experiments should be announced in advance in the future, > so that everyone can know what is going on. Ideally a pointer to a web > page with full details about the experiment, but at least just a quick > mail to the routing working group (and the IPv6 working group in > cases where appropriate) seems reasonable. > > If this is something that requires a policy change I'd be happy to push > it forward. > > Cheers, https://labs.ripe.net/Members/mirjam/ipv6-darknet-experiment From shane at time-travellers.org Fri Nov 23 09:28:30 2012 From: shane at time-travellers.org (Shane Kerr) Date: Fri, 23 Nov 2012 09:28:30 +0100 Subject: [ipv6-wg] [routing-wg] MERIT Darknet Experiment and RPKI alerts In-Reply-To: References: <8380CB55-4728-4866-AC91-7FF3EC5444BC@ripe.net> <509CE360.8010109@CC.UniVie.ac.at> <8BB6437E-6273-4733-BCAE-DD3F652B38C8@ripe.net> <20121113115912.4634ab63@shane-desktop> Message-ID: <20121123092830.04848105@shane-desktop> Daniel, On Friday, 2012-11-23 00:36:46 +0100, Daniel Karrenberg wrote: > > On 13.11.2012, at 11:59 , Shane Kerr wrote: > > > Daniel, > > > > On Tuesday, 2012-11-13 09:36:39 +0100, > > Daniel Karrenberg wrote: > >> > >> On 09.11.2012, at 12:05 , Wilfried Woeber wrote: > >> > >>> Overall, I think this is very dangerous approach, and the wrong > >>> way to start with. > >>> > >>> There might be very good reasons, why a full block of (IPv6) > >>> addresses, or a subset of, ist not (yet) globally visible. > >>> Announcing/Hijacking those addresses may seriously interfere with > >>> local tests or pilot deployment. > >>> > >>> IMHO this should be strictly opt-in, instead of opt-out! > >>> > >>> Wilfried. > >> > >> Wilfried, you are right. The agreement I thought we made with Merit > >> was to use unallocated address space. Apparently a misunderstanding > >> occurred somewhere along the way. We will talk to Merit and correct > >> this. > > > > Possibly such experiments should be announced in advance in the > > future, so that everyone can know what is going on. Ideally a > > pointer to a web page with full details about the experiment, but > > at least just a quick mail to the routing working group (and the > > IPv6 working group in cases where appropriate) seems reasonable. > > > > If this is something that requires a policy change I'd be happy to > > push it forward. > > > > Cheers, > > https://labs.ripe.net/Members/mirjam/ipv6-darknet-experiment Thanks for this link, however in this case this is not a complete answer. I was obviously unclear, so let me try again. 1. This link was not posted *in advance*. The reason I proposed in advance is partially so that we could get review and feedback such as Wilfried's, and prevent future issues. 2. It was not sent to any of the RIPE mailing lists until after problems were reported. RIPE Labs is cool, but AFAIK the RIPE community still lives & breathes in the RIPE working group mailing lists. 3. There is apparently neither a procedure nor a policy concerning notification of experiments. Cheers, -- Shane From fw at deneb.enyo.de Fri Nov 23 18:15:54 2012 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 23 Nov 2012 18:15:54 +0100 Subject: [ipv6-wg] [routing-wg] MERIT Darknet Experiment and RPKI alerts In-Reply-To: <20121123092830.04848105@shane-desktop> (Shane Kerr's message of "Fri, 23 Nov 2012 09:28:30 +0100") References: <8380CB55-4728-4866-AC91-7FF3EC5444BC@ripe.net> <509CE360.8010109@CC.UniVie.ac.at> <8BB6437E-6273-4733-BCAE-DD3F652B38C8@ripe.net> <20121113115912.4634ab63@shane-desktop> <20121123092830.04848105@shane-desktop> Message-ID: <87ehjkb5px.fsf@mid.deneb.enyo.de> * Shane Kerr: > 3. There is apparently neither a procedure nor a policy concerning > notification of experiments. I'm concerned that this is not the first time something went wrong. From training at ripe.net Mon Nov 26 14:06:41 2012 From: training at ripe.net (Training Mailbox) Date: Mon, 26 Nov 2012 14:06:41 +0100 Subject: [ipv6-wg] RIPE NCC Training Courses January-March 2013 - BG, DE, UK, PT, NL, SA, DK, UA, LV, KG In-Reply-To: <50B368A0.6010406@ripe.net> References: <50B368A0.6010406@ripe.net> Message-ID: <50B36961.1080902@ripe.net> 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