- ipv6-wg - mailman.ripe.net

[training] RIPE NCC Training Courses April-June 2013
by Training Mailbox 25 Feb '13

25 Feb '13

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 Sarajevo, Leeds, Dubai, Berlin, Amsterdam, Warsaw, Vaduz, St. Petersburg, Marseilles, Madrid, Budapest, Helsinki. 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 - Database Training Course (new) - IPv6 for LIRs Training Course - Routing Security 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

New on RIPE Labs: SI6 IPv6 Toolkit v1.3.1 Released
by Mirjam Kuehne 22 Feb '13

22 Feb '13

Dear colleagues, Please find a new article on RIPE Labs contributed by Fernando Gont: SI6 IPv6 Toolkit v1.3.1 Released https://labs.ripe.net/Members/mirjam/si6-ipv6-toolkit-v1.3.1-released Kind regards, Mirjam Kuehne RIPE NCC

1 0

SI6 Networks' IPv6 Toolkit v1.3 released!
by Fernando Gont 16 Feb '13

16 Feb '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Folks, We are pleased to release the SI6 Networks' IPv6 Toolkit v1.3: a security assessment and trouble-shooting toolkit for the IPv6 protocol suite. The toolkit is available at: <http://www.si6networks.com/tools/ipv6toolkit>, where you can find a the usual tarball, a PGP-signed version of it, a link to the toolkit's GIT repository, etc. This release has a number of features: * It includes a full-fledged IPv6 address scanning tool (scan6) -- probably the only comprehensive IPv6 address scanning tool out there. Check out all the newly incorporated features! * It includes support for tunnels (in most of the tools). So if you are currently employing e.g. a free IPv6 tunnel to connect to the IPv6 Internet, you'll now be able t play with the tools using your tunnel. * Adds features that have been in our "todo list" for a while: + It includes manual pages in troff format for all the tools. + It includes a makefile, to easily build and install the tools, configuration file, manuals, etc., on your local system. The toolkit runs on (at least) the latest versions of Linux, FreeBSD, NetBSD, OpenBSD, and Mac OS X. Please send any bug reports and/or feature requests to <fgont(a)si6networks.com>. As always, you can get the latest news on IPv6 security research and tools by following us on Twitter: @SI6Networks. Thanks! Best regards, - -- Fernando Gont SI6 Networks e-mail: fgont(a)si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJRH9bJAAoJEK4lDVUdTnSSLzcQALIxgi8HwQkVwLllvV4k0r6L 8ujKx7MDIsyzYZLPSy0sfItHb9g+FJWcSEgpXy2mRoxre9CkRL/sXhlFSHxJWavA zpj5jkIq1IxATuydBj2y4a8UX1IjRsGIouMQAyh9JR0el1hHnLDqnoF0M6/BZ673 c0L4DBiZ3vvX5DzKnR9Ajp3zKydw+N1wkaIqMObWTnXy1FqKABeVo23Ab3Bv3UO+ ++sPRVMePTG+wl0i2E/tPLUYXmrNnrIg+q7TBNDEIGtAufBesjYAOpVZ5/+n7Zit A5e/IA/QAV1MoMnUSvLW6TV5mwK7bV1G1YPpVs5YI78o0ylja7L9vUKh5rff43d4 My3FCNKpkWYH2/qt4rB2A10eUkTyBf7FILYaf+jzacK8/1K/HXySmul2pQ9Uf3ja SE6gpyf4V7aUgkWNF3rsFbWCCmYviwVWI4qwK7rSmVvdziJtxWcRqDQnqE1qZN3k zyjW6Bvb64hnIrH5DD5Ub0gi9N2e8/vYnZA2o1XOo3/Z3Tzt1M9pq+WPpny3cTNM w+B2FtCnBGV0ZK617Mj0UIowZJPE1q/AWImJLuhZwCq3XI8U5lO3uX3r7Ic1v4XW xKTGw21v7WJP+nmIxul2MhKwuIcvlp8f4SYZLDp5fizkohpbIBDqbjbTtjGaE/R4 DQ7dmEOIzBt9fKUq9u9Z =n2U7 -----END PGP SIGNATURE-----

1 0

Regarding RIPE 554
by jaganbabu rajamanickam 06 Feb '13

06 Feb '13

Hello , I am new to RIPE, I was going through the RIPE 554 "Requirement for enterprise / ISP grade Layer 2 switch". I saw list of requirements like a. MLDv2 snooping [RFC4541] b. DHCPv6 filtering [RFC3315] c. Router Advertisement (RA) filtering [RFC4862] d. Dynamic "IPv6 Neighbor solicitation/advertisement" inspection [RFC4861] e. Neighbor Unreachability Detection [NUD, RFC4861] filtering f. Duplicate Address Detection [DAD, RFC4429] snooping and filtering Is there any RFC or draft compliance should be followed for the above. The RFC mentioned above are the protocol RFC and not specific to snooping or filtering. While RIPE 554 testing, what they test against? Thanx, Jags

1 0

Linux as 6RD BR
by Torbjörn Eklöv 24 Jan '13

24 Jan '13

Hi, I am trying to set up a Ubuntu 12.04 as 6RD border router but I can't get it work ok. Google don't give so many hints so I have used http://en.usenet.digipedia.org/thread/18960/18958/ as source. My setup: <script> #My 6rd domain, iproute ( 20111117-1ubuntu2 ) package in Ubuntu 12.04 can only use /32….. PREFIX="2001:db8" # My 6RD BR IP BRIP=1.1.99.1 #Create "loopback", i have tried to use eth0 as BR-interface but it's same problem. ip link add type veth ip a a dev veth0 $BRIP ip l set veth0 up #Create 6rd tunnel interface ip tunnel add 6rd mode sit local $BRIP dev veth0 ttl 64 ip addr add ${PREFIX}::1/32 dev 6rd ip tunnel 6rd dev 6rd 6rd-prefix ${PREFIX}::/32 ip link set 6rd up #Enable IPv6 routing sysctl -w net.ipv6.conf.all.forwarding=1 </script> Then I set up option 212 with: option 6rd code 212 = { integer 8, integer 8, ip6-address, array of ip-address }; option 6rd 0 32 2001:db8:: 1.1.99.1; The problem is that when I use the tunnel ( ping6 ${PREFIX}::1 for example ) I get "icmp port unreachable" for the traffic ( protocol 41 ) to BRIP/1.1.99.1 The icmp originates from my BRIP so everything looks ok. except that it don't work. :) A route to 2001:db8::/32 through dev 6rd is automatically created when I run my script. Has anyone done this or used other OS like *BSD, other Linux or what should I do??? I have tried to use the newest iproute2 package from source but it don't help either. /Torbjörn Eklöv mobil: 070 - 683 51 75 Lync: torbjorn.eklov(a)interlan.se<mailto:torbjorn.eklov@interlan.se> Skype: torbjorn.eklov http://www.interlan.se http://www.dnssecandipv6.se<http://www.dnssecandipv6.se/>

2 2

Last Mile: COMPUTATION TOOLS 2013 || May 27 - June 1, 2013 - Valencia, Spain
by Sandra Sendra 11 Jan '13

11 Jan '13

INVITATION: ================= Please consider to contribute to and/or forward to the appropriate groups the following opportunity to submit and publish original scientific results to COMPUTATION TOOLS 2013. The submission deadline is extended to January 27, 2013. Authors of selected papers will be invited to submit extended article versions to one of the IARIA Journals: http://www.iariajournals.org ================= ============== COMPUTATION TOOLS 2013 | Call for Papers =============== CALL FOR PAPERS, TUTORIALS, PANELS COMPUTATION TOOLS 2013, The Fourth International Conference on Computational Logics, Algebras, Programming, Tools, and Benchmarking May 27 - June 1, 2013 - Valencia, Spain General page: http://www.iaria.org/conferences2013/COMPUTATIONTOOLS13.html Call for Papers: http://www.iaria.org/conferences2013/CfPCOMPUTATIONTOOLS13.html - regular papers - short papers (work in progress) - posters Submission page: http://www.iaria.org/conferences2013/SubmitCOMPUTATIONTOOLS13.html Submission deadline: January 27, 2013 Sponsored by IARIA, www.iaria.org Extended versions of selected papers will be published in IARIA Journals: http://www.iariajournals.org Print proceedings will be available via Curran Associates, Inc.: http://www.proceedings.com/9769.html Articles will be archived in the free access ThinkMind Digital Library: http://www.thinkmind.org Please note the Poster and Work in Progress options. The topics suggested by the conference can be discussed in term of concepts, state of the art, research, standards, implementations, running experiments, applications, and industrial case studies. Authors are invited to submit complete unpublished papers, which are not under review in any other conference or journal in the following, but not limited to, topic areas. All tracks are open to both research and industry contributions, in terms of Regular papers, Posters, Work in progress, Technical/marketing/business presentations, Demos, Tutorials, and Panels. Before submission, please check and conform with the Editorial rules: http://www.iaria.org/editorialrules.html COMPUTATION TOOLS 2013 Topics (topics and submission details: see CfP on the site) Logics Reasoning logics; Fuzzy logics; Semantic logics; Temporal logics; Emotion logics; Ambiant logics; Modal logics; Description logics; Computational tree logic; Computational logics and constraints; Quantum computational logics; Executable computational logics; Monadic computational logics; Many-valued computational logics; Computability logic Algebras Computational algebras; K-theories, C*-algebras, Index theory; Algebraic and topological K-theory; Geometric group theory and group C*-algebras; Noncommutative geometry and topology; Pseudodifferential operators on singular manifolds; Topological invariants of non-simply connected manifolds; Deformation quantization; Lambda calculus; Relation algebra; Algebras for symbolic computation; Constructive algebras Advanced computation techniques Machine learning; Fuzzy theory/computation/logic; (Artificial) neuronal networks; Distributed artificial intelligence; Genetic algorithms; Analytic tableaux; Autonomous agent-based techniques; Knowledge-based systems and automated reasoning; Logical issues in knowledge representation /non-monotonic reasoning/belief; Dempster-Shafer theory; Concurrent computation and planning; Deduction and reasoning Specialized programming languages Logic programming; Specialized computation languages; Real-time computation languages; Embedded-computing languages; Programming semantics; Content-driven programming; Multimedia-oriented programming; Context-driven programming; Service-oriented programming; Pattern-oriented programming; Regenerative programming; Progressive programming; Sensing-oriented programming; Mobile-ubiquity-oriented computing; Compilation issues Tools for distributed computation Platforms for distributed computing; Specification and verification of programs and systems; Techniques for cloud computing; On-request resource allocation mechanisms; Security and privacy techniques; Computational benchmarking metrics, criteria and methodologies; Distributed debug and on-fly repairing; Inference of schemas, integrity constraints in computational applications; Real-world applications, experiments, projects ------------------------------------------- Committee: http://www.iaria.org/conferences2013/ComCOMPUTATIONTOOLS13.html ================================================

1 0

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

Draft agenda RIPE 66 version 1
by MarcoH 20 Dec '12

20 Dec '12

We still have a long way to go until we meet in May in Dublin, but we have the first draft of the agenda online :) https://ripe66.ripe.net/programme/meeting-plan/ipv6-wg/ > Draft IPv6 Working Group Agenda - Version 1 > > Session 1 – Wednesday, 15 May 13:00 – 15:30 (Main Room) > A) Welcome and Administrative Business > > B) “Progress in DHCPv6″ > Internet Software Consortium – Speaker TBC > > C) “Implementing Full IPv6 Support: More than Binding to an AF_INET6 Socket” > Bert Hubert, PowerDNS/Netherlabs > > > Session 2 – Thursday, 16 May 09:00 – 10:30 (Side Room) > A) IPv6 Measurements Panel > Organisers: > - Marco Hogewoning, RIPE NCC > - Meredith Whittaker, Google/M-Lab > > X) Close As you can see, we still have plenty of room for more talks.If you have a topic that you think is interesting or relevant, please drop us note. Merry Christmas, The IPv6 Working Group chairs, Marco, David and Shane

1 0

(Not a) call for content for RIPE 66
by Marco Hogewoning 15 Dec '12

15 Dec '12

Dear colleagues, Preparations already started for RIPE 66. Please take a moment of your time and help in this process by telling us which topics, technologies or speakers would you like to see in Dublin. Our working group is chartered to take on "anything useful in helping people to deploy IPv6, and to manage IPv4/IPv6 co-existence", why not write it in with that one question you would really like to get answered. As part of our two 90 minute slots, we are thinking of dedicating a portion to a measurements theme track. The questions we would like to ask there is where measurements become useful to your IPv6 deployment, or to rephrase, which measurements would you like to see? Help us shape the agenda by providing your feedback. Reply to the list and you may find yourself amongst likeminded people. Of course if you have this wonderful IPv6 project or idea you would like to share, we are always open for suggestions. Please submit a short description of your talk to IPv6-wg-chairs [at] ripe [dot] net. Merry christmas and hope to see you all in Dublin, On behalf of IPv6 Working Group Chairs, Marco Hogewoning

1 0