- ipv6-wg - mailman.ripe.net

Special Issue on "Underwater Sensor Networks" in (JSAN)
by Sandra Sendra 28 May '14

28 May '14

=================================================== Journal of Sensor and Actuator Networks (JSAN) Special Issue "Underwater Sensor Networks" http://www.mdpi.com/journal/jsan/special_issues/usn Deadline for manuscript submissions: 30 September 2014 ---------------------------------------------------- === SPECIAL ISSUE === New advances in information technologies, circuits, systems and communication protocols have made possible the deployment of underwater sensor networks. These issues have lead researchers to propose new underwater sensor nodes, sensor node placement, protocols for their communication, architectures, and study new ways to communicate with higher bandwidth at higher distances. Moreover, the range of underwater applications is growing fast because of the last research in oceanography, marine science and aquiculture, so there is a need of underwater sensor networks in order to support these disciplines. This special Issue is tries to collect unpublished works on theory and practice on underwater sensor networks, with special interest on real implementations and deployments. We also seek new proposals on wireless communication technologies. === KEYWORDS === The Special Issue "Underwater Sensor Networks" topics include (but are not limited to) the following: - Underwater sensor nodes - Underwater sensor node placement - Routing protocols for underwater sensor networks - Underwater communications - Underwater architectures - Underwater wireless communications - Underwater sensor network deployments === SUBMISSION === Manuscripts should be submitted online at www.mdpi.com by registering and logging in to this website. Once you are registered, click here to go to the submission form (http://www.mdpi.com/user/manuscripts/upload/?journal=jsan). Manuscripts can be submitted until the deadline. Papers will be published continuously (as soon as accepted) and will be listed together on the special issue website. Research articles, review articles as well as communications are invited. For planned papers, a title and short abstract (about 100 words) can be sent to the Editorial Office for announcement on this website. Submitted manuscripts should not have been published previously, nor be under consideration for publication elsewhere (except conference proceedings papers). All manuscripts are refereed through a peer-review process. A guide for authors and other relevant information for submission of manuscripts is available on the Instructions for Authors page. Journal of Sensor and Actuator Networks is an international peer-reviewed Open Access quarterly journal published by MDPI. Please visit the Instructions for Authors page (http://www.mdpi.com/journal/jsan/instructions) before submitting a manuscript. For the first couple of issues the Article Processing Charge (APC) will be waived for well-prepared manuscripts. English correction and/or formatting fees of 250 CHF (Swiss Francs) will be charged in certain cases for those articles accepted for publication that require extensive additional formatting and/or English corrections. === SPECIAL ISSUE EDITORS === Guest Editors Prof. Dr. Jaime Lloret Mauri (jlloret(a)dcom.upv.es) Integrated Management Coastal Research Institute, Polytechnic University of Valencia, Camino de Vera 46022, Valencia, Spain Dr. Sandra Sendra (sansenco(a)posgrado.upv.es) Integrated Management Coastal Research Institute, Polytechnic University of Valencia, Camino de Vera 46022, Valencia, Spain ===================================================

1 0

Re: [ipv6-wg] Vacancy - nominations can go here
by Roger Jørgensen 22 May '14

22 May '14

On Sat, May 17, 2014 at 7:37 PM, Jan Zorz @ go6.si <jan(a)go6.si> wrote: <snip> > But now we've got 3 very good candidates - Jen, Dave and Benedikt - and I > think we should rotate them in. Excellent suggestion, let's rotate Jen, Dave and Benedikt in. -- Roger Jorgensen | ROJO9-RIPE rogerj(a)gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger(a)jorgensen.no

12 13

Resignation as co-chair of ipv6
by David Kessens 22 May '14

22 May '14

Hi, My personal circumstances have changed in such a way that I most recently did not spent as much time and effort for the ipv6 working group as it deserves. At the same time, I have served the working group for over 15 years and it would certainly not be unreasonable to think that it is good for the working group to change direction. Considering the above, I have decided to resign as co-chair of the ipv6 working group. I hope that this change will give a chance to a new generation of RIPE participants to play a role as a chairperson of a working group and as a participant in the RIPE working group chair collective. Thanks, David Kessens ---

7 6

Follow-Up on Niall's talk: Ramond (RA Monitoring Daemon)
by Benedikt Stockebrand 21 May '14

21 May '14

Hi folks, after his presentation learned from Niall that he didn't actually know about the ramond, so here's some quick info for all who have a similar situation like him: Ramond is a little tool that listens for RAs and then matches the source MAC address or whatever with a list of authorized routers. It can clean up after rogue router RAs by sending a follow-up RA with router lifetime of 0 and deprecating all the advertised prefixes, and it can also run some external programs/scripts to do additional clean up (like an automated retaliation strike). It's open source and should run on all standard Unixes (so far I've only tested it on Linux myself), and of course it can be combined with 802.1Q. I've also covered it in the second half of my video blog episode at http://www.stepladder-it.com/bivblog/23 with the most relevant parts starting at about 15:00 into the video. If you handle networks with a potential for rogue advertising routers and don't know about the tool, I recommend you take a look at it. Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/

6 11

Vacancy - nominations can go here
by MarcoH 21 May '14

21 May '14

Hi, As just mentioned, we are looking for new co-chairs for the IPv6 Working Group. If you need more info of what is involved feel free to ask Shane or me. We will send a more lengthy mail regarding process later. In the meantime we welcome nominations. For consistency, please reply to this thread so all nominations are grouped. MarcoH -- Sent from mobile, sorry for the typos

12 13

Introducing the IPv6 Analyser
by Alex Band 20 May '14

20 May '14

Dear colleagues, You can now visit the LIR Portal and try out seamless RIPE Database object creation using the IPv6 Analyser: https://www.ripe.net/s/zToA The IPv6 Analyser is a toolset that offers our members a visual insight into all the allocations, aggregations and assignments they have made. This is the first toolset that seamlessly integrates with the RIPE Database, allowing you to create new objects with an easy-to-use wizard that guides you through the process, searching for available space, and pre-filling known information. Our goal is to unify resource management in the LIR Portal by extending these design principles to organisation, routing and Reverse DNS management. Now that the core design is available, we very much look forward to your feedback on how we can make the IPv4 and IPv6 Analyser as useful as possible. Kind regards, Alex Band Product Manager RIPE NCC

1 0

IEEE International Workshop on Cloud-integrated Cyber Physical Systems 2014 (IEEE Cloud-CPS 2014)
by Sandra Sendra 20 May '14

20 May '14

********************************************************* CALL FOR PAPERS IEEE International Workshop on Cloud-integrated Cyber Physical Systems 2014 (IEEE Cloud-CPS 2014) Submission due July 31, 2014 http://cloudcps.cwins.org Dec 15 � 18, 2014, Singapore Singapore in conjunction with IEEE CloudCom 2014, Dec 15 � 18, 2014, Singapore ******************************************************************** Technology has gone through tremendous changes in terms of computing, communications and control to provide wide range of applications in all domains. This advancement provides the opportunities to bridge the physical components/processes and the cyber space leading to the Cyber Physical Systems (CPS). The notion of CPS is to use computing (sensing, analyzing, predicting, understanding, etc.), communication (interaction, intervene, interface management, etc.) and control (inter-operate, evolve, evidence-based certification, etc.) to make intelligent and autonomous systems. Such systems are playing an increasingly prevalent and important role in this electronic era such as healthcare, manufacturing, civil infrastructure, aerospace, entertainment, transportation and many automated physical systems. Computing and networking are two major components of CPS and Cloud has infinite resources for both. Cloud-integrated CPS will not only enhance CPS itself but also process, analyze! and manage (CPS) big data efficien tly. However, there are many issues and hurdles of Cloud-integrated CPS that need discussions. Our aim is to provide a platform for researchers and practitioners to present their research results in the area of Cloud-integrated Cyber-Physical Systems. The proposed workshop CloudCPS-2014 will serve as a forum for researchers from academia, government and industries to exchange ideas, present new results and provide future visions on these topics. Topics of interest include but not limited to: - Cloud-CPS Architecture - Cloud-CPS Modeling and Simulation - Virtualization of Physical Components in Cloud-CPS - Design and Performance Optimization in Cloud-CPS - Cloud-assisted Situation-aware and decision support - Big-data Processing and Visualization in Cloud-CPS - Mobile Cloud-CPS - Game Theory for Cloud-CPS - Tools and Methods for Cloud-CPS - Sensor-actuator Networks - Security, Privacy, and Trust in Cloud-CPS - Intelligent (Road/Air) Transportation Cloud-CPS - Cloud-CPS in healthcare - Cloud-CPS in energy - Fog computing - Cloud-CPS: Tools, test beds and deployment issues - Opportunistic spectrum access for Cloud-CPS ***************************** SUBMISSION INSTRUCTIONS ***************************** The authors are advised to submit their research paper following the IEEE CS format: two columns, single-spaced, including figures and references, using 10 fonts, and number each page. Instructions for authors how to format the manuscript can be found at: http://www.computer.org/portal/web/cscps/submission/ http://www.computer.org/portal/web/cscps/formatting/ The following templates below, are general templates designed for conferences using an US Letter (8.5" x 11") trim size. MS Word Template: http://www.computer.org/portal/c/document_library/get_file?uuid=4cc57ba2-39… LaTeX Package: http://www.computer.org/portal/c/document_library/get_file?uuid=cda2f9b2-51… Papers will be carefully evaluated based on originality, significance, technical soundness, and clarity of exposition. The papers, in pdf format, should be submitted electronically through https://www.easychair.org/conferences/?conf=ieeecloudcps2014. If there is any problem during submission, please contact the workshop general chairs or db.rawat(at)ieee.org. All accepted papers will be published by IEEE CS Press (submitted to IEEEXplore) and submitted for indexing by EI and ISSN. *********************** Important Dates *********************** Deadline for paper submissions: July 31, 2014 Notification of Paper acceptance: Sept. 2, 2014 Deadline for camera-ready: Sept.16, 2014 Deadline for author registration: Oct. 1, 2014 Conference: December 15-18, 2014 WORKSHOP WEBSITE For more information, please visit the workshop website at http://cloudcps.cwins.org ++++++++++++++++ Organizers ++++++++++++++++ **************** General Chairs **************** Ivan Stojmenovic, University of Ottawa, Canada Danda B. Rawat, Georgia Southern University, USA Jaime Lloret Mauri, Polytechnic University of Valencia, Spain ****************** Program Chairs ****************** Bhed B. Bista, Iwate Prefectural University, Japan Song Guo, The University of Aizu, Japan ******************* Publicity Chairs ******************* Sandra Sendra, Polytechnic University of Valencia, Spain

1 0

IPV6 IPV4 work around
by Timothy Roy 19 May '14

19 May '14

Hi to All, I mentioned this a the Meeting in Warsaw but not sure if anyone really understood so I will submit it again. I realize that there will still be a lot of networks that will have to be able to translate over to IPV4 from IPV6 and vice versa. I also know that most are not too willing to obtain another piece of equipment for their system, but using a LTM (F5 LTM (which is what we will be using this year)) to do the translation from IPV6 to IPV4. This would be an excellent work around for quite a few issues that I have read about such as email. I have not tested this with email but will be testing it with our DNS very soon as I want to get our system on the IPV6 Internet so to speak. Just a thought and would also like to hear from anyone that may have already done so or tried to. Best Regards Tim Timothy Roy Regulatory and Compliance Unit Domain Name Operations Telecommunications Regulatory Authority. Tel: +968 24574858 Mobile: +968 93551117 Email: timothy(a)tra.gov.om<mailto:timothy@tra.gov.om> Office hours: Sunday - Thursday, 7:30am - 3:00pm (Muscat GMT +4)

2 1

[training] RIPE NCC Webinars - new dates
by Training Services 19 May '14

19 May '14

Dear colleagues, We are pleased to announce the launch of new dates for our Webinars. The RIPE NCC Webinars are live and take only one hour. You can interact with our trainers without leaving your desk. 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 <training(a)ripe.net>. We look forward to seeing you online. Kind regards, RIPE NCC Training Services

1 0

Discrepancies within ripe-554
by Cudok, Dr. Andreas 15 May '14

15 May '14

Dear Sirs, while reading ripe-554 (http://www.ripe.net/ripe/docs/ripe-554) carefully, I found the following discrepancies: 1. In section "Requirements for network security equipment" you say that "For every mandatory standard the applicable subgroups are specified in parentheses at the end of the line". Then within "Mandatory Support" you can find the following line: "Deprecation of Type 0 Routing Headers in IPv6 [RFC5095]*". Does the omission of any applicable subgroup mean, that this requirement is not applicable to any subgroup (where the "*" just indicates that this is a requirement for "IPv6 Ready Logo" only), or does it in contrast mean, that this requirement is implicitly applicable to all 3 subgroups FW, IFS and APFW? 2. Within "Optional Support" of section "Requirements for network security equipment" with one exception no applicable subgroups are specified. Does this mean, that these optional requirements are implicitly applicable to all 3 subgroups FW, IFS and APFW? But then no applicable subgroup should be mentioned at all, hence the one exception I mentioned causes confusion: "Using IPsec to Secure IPv6-in-IPv4 Tunnels [RFC4891] (FW)". And you are embarrassed even more when you see the following a few lines later: "Using IPSec to Secure IPv6-in-IPv4 Tunnels [RFC4891]". Hence, I assume that the first line "Using IPsec to Secure IPv6-in-IPv4 Tunnels [RFC4891] (FW)" is an error and has to be wiped out? 3. Within "Mandatory Support" of section "Requirements for network security equipment" you find "If the request is for a dynamic internal gateway protocol (IGP), then the required . , OSPF-v3 [RFC5340] . must be supported." while within "Optional Support" of section "Requirements for network security equipment" you will see: "OSPF-v3 [RFC5340]". Can you explain this contrariety? 4. Within "Mandatory Support" of section "Requirements for network security equipment" you find "If OSPF-v3 is requested, the device must support "Authentication/Confidentiality for OSPFv3" [RFC4552] (FW, IPS, APFW)" while within "Optional Support" of section "Requirements for network security equipment" you will see: "Authentication/Confidentiality for OSPF-v3 [RFC4552]". Can you explain this contrariety? Your answers are welcome! Kind Regards DATEV eG Dr. Andreas Cudok Paumgartnerstr. 6-14 D 90329 Nürnberg Phone +49(911)319-4031 Mail andreas.cudok(a)datev.de <mailto:andreas.cudok@datev.de> _____ Diese E-Mail wurde mit einem Zertifikat der DATEV eG signiert. Damit können Sie sicher sein, dass die Nachricht so von uns gesendet wurde. Wenn Sie eine Meldung erhalten, dass die Signatur ungültig ist oder nicht geprüft werdenkann, fehlt das Zertifikat zu dieser Signatur auf Ihrem Rechner. Informationen zu Zertifikaten und zur digitalen Signatur finden Sie unter www.datev.de/zertifikate im Internet. _____ DATEV eG 90329 Nürnberg Sitz: 90429 Nürnberg, Paumgartnerstraße 6-14 Registergericht Nürnberg, GenReg Nr. 70 Telefon +49 911 319-0 Telefax +49 911 319-3196 E-Mail info(a)datev.de Internet www.datev.de Vorstand Prof. Dieter Kempf (Vorsitzender) Dipl.-Kfm. Wolfgang Stegmann (stellvertretender Vorsitzender) Dipl.-Kfm. Dr. Robert Mayr Jörg Rabe v. Pappenheim Dipl.-Vw. Eckhard Schwarzer Vorsitzender des Aufsichtsrates: Reinhard Verholen

1 0

Language smoothing
by Timothy Roy 15 May '14

15 May '14

I work for the Oman TRA, and just want to let you know that if you need English/American language smoothing in the groups docs I am willing to assist in this. Best Regards Tim Roy Sent from my iPhone

1 0

IPv6 Only Testbed at RIPE68
by Marco Hogewoning 15 May '14

15 May '14

Dear colleagues, Welcome to Warsaw. Following the discussion at RIPE 66, and a successful experoment in Athens last autumn, the IPv6 Working Group is happy to provide you with an experimental network that is configured to offer only IPv6. Please note this experimental network is not supported by the RIPE NCC or RIPE 68 Technical Team. We encourage everybody to connect to this network and test any websites, applications, hardware and software, and verify that they operate when an IPv4 address is no longer available. Important: This network is an experiment and is offered on a best-effort basis. We will try to maintain sufficient service levels and are happy to look into and help troubleshoot any issues you may encounter. If you rely on network connectivity for important business, we recommend you connect to the regular RIPE Meeting network. How to connect: - Make sure IPv6 is enabled on your device - Connect to SSID: IPV6ONLYEXP (5GHz) or IPVONLYEXP2.4 (2.4 GHz) - Enter the password: iknowbesteffort The network provides NAT64 translation to connect to legacy services – please use the name server provided by the network to make use of this feature. We suggest you leave IPv4 enabled as this will be the scenario for most end users. If you have any feedback or questions please try and find me or post it to this list. Of course we also welcome any feedback during our working group sessions on Thursday. And once again big thanks to Andrew Yourtchenko, Cisco and the RIPE NCC staff who helped setting this up and provided the necessary equipment and software. Greetings, Marco Hogewoning co-chair of the IPv6 working group

4 3

[training] RIPE NCC Training Courses July-September 2014
by Training Services 12 May '14

12 May '14

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 Valencia, Tirana, Vilnius, Budapest, Tel Aviv, Samara, Düsseldorf, Stockholm, Belfast, Amsterdam, Ankara. 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 - Basic IPv6 Training Course - Routing Security Training Course - 2 day Advanced Training Course - DNSSEC Training Course - Measurements Tools workshop For more information visit: http://www.ripe.net/lir-services/training/courses With kind regards, Rumy Spratley-Kanis Training Services Manager

1 0

Draft IPv6 working group agenda for RIPE 68 ("T: -9 days" edition)
by Shane Kerr 06 May '14

06 May '14

IPv6 WG participants, Here's an updated version of our working group agenda. There are two changes: 1. Fixed a typo on Helge Holz's name 2. Added a talk about IPv6 Deployment at CERN by Edoardo Martelli We have two 90-minute slots in Warsaw: 2014-05-15 09:00-10:30 (Thursday 1st morning slot) 2014-05-15 11:00-12:30 (Thursday 2nd morning slot) We'll have to change rooms, but happily the slots are on the same day, so we can maintain our focus on IPv6 topics without other distractions. Our current plan: 5 minutes Session Booting & Initialization 20 minutes IPv6 Penetration in Hungary Janos Zsako 20 minutes Painting by Numbers (Visualization of Structured IPv6-Addressing) Helge Holz 15 minutes RIPE 554bis (Requirements for IPv6 in ICT Equipment... revised!) Jan Zorz / Sander Steffann 15 minutes RIPE IPv6 Analyser Alex Band 15 minutes BCOP document: "IPv6 troubleshooting procedures for helpdesks" Benno Overeinder / Jan Zorz 15 minutes IETF document: "Balanced Security for IPv6 Residential CPE" Ragnar Anfinsen 15 minutes IPv6 Campus Deployment Experience Niall O'Reilly 15 minutes IPv6 Deployment at CERN Edoardo Martelli 10 minutes Session Shutdown Slides have already started arriving for the presentations (thanks Niall!): https://ripe68.ripe.net/presentations/presentation-archive/ See you in Warsaw! On behalf of your IPv6 working group chairs, -- Shane

1 0

Fwd: Updates to RIPE-500: Policy Development in RIPE
by Marco Hogewoning 04 May '14

04 May '14

Dear Working Group, For those who are not subscribed to RIPE list, please see the following message from Hans Petter regarding updating the Policy Development Process. Feedback should be posted to RIPE list! Greetings, MarcoH Begin forwarded message: > From: Hans Petter Holen <hph(a)oslo.net> > Subject: Updates to RIPE-500: Policy Development in RIPE > Date: 4 mei 2014 13:55:55 CEST > To: ripe-list(a)ripe.net > > Dear colleagues, > The Working-group chairs have for some time been discussing how to improve the Policy Development Process as described in RIPE-500. A small task force with Brian Nisbet as the coordinator and Ondrej Filip, Nick Hilliard and Hans Petter Holen as members has worked out the final details in the text. > > The wg-chairs have reached consensus on the attached proposal. > > The main change in the PDP is to allow the Working-group Chairs of the working-group developing the policy to declare consensus. > > This allows for a more timely conclusion of the PDP, but also allows for the Working-group chairs collectively to act as an appeals body. > > I am circulating the new text now for community review and the intent is to put this in place at the coming RIPE meeting. > > > Yours Sincerely, > > Hans Petter Holen > RIPE Deputy Chair > >

1 0

IEEE TrustCom Deadline is Approaching: May 5, 2014
by Sandra Sendra 25 Apr '14

25 Apr '14

[Please accept our apologies if you receive multiple copies of this email] *********************** CFP ******************************* The 13th IEEE International Conference on Trust, Security and Privacy in Computing and Communications (IEEE TrustCom-14) http://www.greenorbs.org/TrustCom2014/ 24-26 September 2014, Beijing, China Important Dates Workshop Proposal: May 5, 2014 Submission Deadline: 11:59PM (UTC/GMT+8 hours) May 5, 2014 (This is the firm deadline) Authors Notification: June 26, 2014 Final Manuscript Due: July 20, 2014 Publications Accepted and presented papers will be included in the IEEE CPS Proceedings. Distinguished papers presented at the conference, after further revision, will be published in special issues of the following high quality international journals (pending). - Computers & Security - Elsevier (Impact factor=0.868) - Concurrency and Computation: Practice and Experience - Wiley (Impact factor=0.636) - Security and Communication Networks - Wiley (Impact factor=0.414) - Future Generation Computer Systems - Elsevier (Impact factor=1.978) - Multimedia Tools and Applications - Springer (Impact factor=0.617) - Journal of Internet Technology (Impact factor=0.508) - Journal of Computer and System Sciences - Elsevier (Impact factor=1.157) Topics Trust Track - Trust semantics, metrics and models - Trusted computing platform - Trusted network computing - Trusted operating systems - Trusted software and applications - Trust in social networks - Trust in e-commerce and e-government - Trust in mobile and wireless communications - Risk and reputation management - Survivable computer systems/networks - Miscellaneous trust issues Security Track - Network security - Computer security - Database security - Web applications security - Security policy, model and architecture - Security in social networks - Security in parallel and distributed systems - Security in mobile and wireless communications - Security in grid/cloud/pervasive computing - Authentication, authorization and accounting - Miscellaneous security issues Privacy Track - Privacy in Web-based applications and services - Privacy in database systems - Privacy in parallel and distributed systems - Privacy in grid/cloud/pervasive computing - Privacy in mobile and wireless communications - Privacy in e-commerce and e-government - Privacy in network deployment and management - Privacy and trust - Privacy and security - Privacy and anonymity - Miscellaneous privacy issues Organisation Committee General Chairs: Jiaguang Sun, Tsinghua University, China Ivan Stojmenovic, University of Ottawa, Canada Program Chair: Yunhao Liu, Tsinghua University, China Publicity Chairs: Sandra Sendra Compte, Polytechnic University of Valencia, Spain Haojin Zhu, Shanghai Jiao Tong University, China Xiaodong Lin, University of Ontario Institute of Technology, Canada Workshop Chairs: Yang Xiang, Deakin University, Australia Kouichi Sakurai, Kyushu University, Japan Publication Chair: Jemal Abawajy, Deakin University, Australia Steering and Program Committees: Please see http://www.greenorbs.org/TrustCom2014/

1 0

Draft IPv6 working group agenda for RIPE 68
by Shane Kerr 23 Apr '14

23 Apr '14

Beloved IPv6 fans, RIPE 68 is rapidly approaching, and as always your trusty working group chairs have been putting together an agenda. We have two 90-minute slots in Warsaw: 2014-05-15 09:00-10:30 (Thursday 1st morning slot) 2014-05-15 11:00-12:30 (Thursday 2nd morning slot) We'll have to change rooms, but happily the slots are on the same day, so we can maintain our focus on IPv6 topics without other distractions. Our current plan: 5 minutes Session Booting & Initialization 20 minutes IPv6 Penetration in Hungary Janos Zsako 20 minutes Painting by Numbers (Visualization of Structured IPv6-Addressing) Heige Holz 15 minutes RIPE 554bis (Requirements for IPv6 in ICT Equipment... revised!) Jan Zorz / Sander Steffann 15 minutes RIPE IPv6 Analyser Alex Band 15 minutes BCOP document: "IPv6 troubleshooting procedures for helpdesks" Benno Overeinder / Jan Zorz 15 minutes IETF document: "Balanced Security for IPv6 Residential CPE" Ragnar Anfinsen 15 minutes IPv6 Campus Deployment Experience Niall O'Reilly 10 minutes Session Shutdown Careful observers will notice that we do still have time available. It's your working group, so if you have anything IPv6-related to discuss, you may still have a chance. See you in Warsaw! On behalf of your IPv6 working group chairs, -- Shane

1 0

Fw: [ipv6hackers] Arin down to 1.0 /8 IPv4 addresses
by Shane Kerr 23 Apr '14

23 Apr '14

All, For those who missed it... Cheers, -- Shane Begin forwarded message: Date: Wed, 23 Apr 2014 13:38:16 +0200 From: Marc Heuse <mh(a)mh-sec.de> To: IPv6 Hackers Mailing List <ipv6hackers(a)lists.si6networks.com> Subject: [ipv6hackers] Arin down to 1.0 /8 IPv4 addresses Hi guys, fyi: as it seems Akamai got 104.64.0.0/10 yesterday. This was 1/5 of the overall IPv4 addresses left for north america, more than 4 million IPv4 addresses. So now Arin has only 1 (aggregated) /8 left for addressing, which means that last phase of (phase four) should be initiated the next days ... My prediction on this was mid of May 2014, so I was off by 3-4 weeks. Please start to go into panic mode now :-) (if you are in north america) Greets, Marc -- Marc Heuse www.mh-sec.de PGP: AF3D 1D4C D810 F0BB 977D 3807 C7EE D0A0 6BE9 F573 _______________________________________________ Ipv6hackers mailing list Ipv6hackers(a)lists.si6networks.com http://lists.si6networks.com/listinfo/ipv6hackers

1 0

Proposed presentation for RIPE68: IPv6 Campus Deployment Experience
by Niall O'Reilly 16 Apr '14

16 Apr '14

Hello. It there's still agenda time available in this WG's slots at RIPE 68, I'ld like to report on recent experience deploying IPv6 on UCD's main campus. I think 15 minutes including questions would be ideal, but can squeeze or stretch as appropriate. ATB /Niall

1 0

Draft minutes RIPE 67
by Marco Hogewoning 15 Apr '14

15 Apr '14

Dear working group, Attached are the draft minutes of the RIPE 67 sessions, as prepared by the RIPE NCC. Apologies for the delay in getting these published, as you can see it is a rather long document this time. Please have a look and report any errors or omissions to this list or directly to chairs. Deadline is 10 april 2014, after which we hope that we can conclude there is consensus to publish these on the website. Again thanks for your cooperation and the lively debates we had in Athens and hope to see you back in Warsaw. Regards, MarcoH on behalf the IPv6 WG chairs — IPv6 Working Group Date: 16 October 2013, 14:00 - 15:30 Chairs: David Kessens, Shane Kerr, Marco Hogewoning Scribe: Emile Aben Session I A. Welcome and Housekeeping Marco Hogewoning opened the first session. The minutes from the last IPv6 Working Group session at RIPE 66 in Dublin were approved. B. Global State of IPv6 Deployment Since IPv6 Launch Geoff Huston, APNIC The presentation is available at: https://ripe67.ripe.net/presentations/115-2013-10-16-ipv6-launch-365.pdf Blake Lillis, L33 Networks, was wondering if IPv4 is actually getting worse rather than IPv6 getting better. Geoff said he doesn't think it's IPv4 getting worse. It is actually pretty amazing to see that IPv6 is getting faster and better. Lee Howard, Time Warner Cable, confirmed that this is consistent with what he is seeing in their network: most of the time IPv6 is performing better. He asked Geoff if he had any guesses as to why. Geoff said he doesn't at the moment but will look through the data for clues. Tore Anderson, Redpill-Linpro, noticed that Opera was on the slides. They are running a proxy service for their browser. Their users are not necessarily on IPv6, they are not even in Norway, and the servers are not in the country either. But it makes Norway look good. He asked if Geoff is counting the number of hits, or the number of addresses. Geoff responded that they are indeed counting the number of hits. Tore noticed that Google's data for Norway was up to 9%, and was wondering if Geoff should compensate for the Opera case. Geoff said the best way to top IPv6 statistics is to deploy IPv6. There were no further questions. C. Terastream IPv6 Details Peter Löthberg & Mikael Abrahamsson, T-systems The presentation is available at: https://ripe67.ripe.net/presentations/251-ripe2-4.pdf Peter stressed after his presentation that he is really looking for feedback. Geoff Huston pointed out that the current IPv6 address policies doesn't seem to correlate with what Peter is trying to do. Peter said this is why this is presented here at the RIPE Meeting, which is the forum that develops address policy in this region. This is something that wasn't really anticipated when we started with IPv6. That's why he is looking for feedback here. He tried to convince people to use variable length addresses, but that was refused in 1994. But how many bits will be needed is what needs to be discussed here. He is suggesting to use address bits to build a better Internet. But he really needs feedback from the community, especially before this will be implemented. Geoff agreed and stressed that this is certainly a change that one needs to think about. Peter explained that when they were not allowed to do variable length addresses back in the 90s, they came up with extension headers. So, even if things today, there is still enough for the future. Mikael clarified that they are not proposing to use more addresses for customers than is allowed by policy today. Peter added that someone was saying that giving a /56 to customers is overkill. But he really wants to avoid putting a NAT box in. Martin Levy (Hurricane Electric) asked if there is anything in the IPv6 address you are exposing to the world that you maybe shouldn't be exposing? And haven't we learned by now that if we do static splits in the address, we're going to run out at some point. Peter explained that there is no information here that you don't also have in any other IPv4 system today. Some bits tell you the geography, some tell you something about the network topology. But they can be randomised like it is happening in IPv4. He said he has a hard time understanding why people worry about that while they carry a phone with a fixed phone number. And no, he is not worried to run out of addresses anytime soon. Peter further elaborated on programmatic responses for reverse DNS for IPv6 address blocks and mentioned DNSSEC being a problem in that. There is a possible DOS against generating a programmatic answer and then sign it on the fly. Scott Leibrand (Limelight Networks) said he's failing to capture the exact magnitude of the address block Peter is planning to request from the RIR. He's not so worried about the 6 bits-part, but more about the 13+14 bits, which is more relevant to the potential of exhausting IPv6 space. Peter said he wanted to show the concept, that's why there are no actual numbers on the slides. After more discussion on bit-level details Scott and Peter decided to discuss this further face to face at a later time. Dimitris Kalogeras (GRNET) pointed out the need for a trigger mechanism if prefixes disappear at a specific time. Currently there is nothing like that yet in operating systems. He was also curious as to why Peter didn't use the diffserv approach. Peter answered that the trigger mechanism merits a longer discussion. And he wanted the customer to be able to use the DiffServ bits. There were no further questions. D. NIC.CZ GEN6 Project Zuzana Duračinská, CZ.NIC The presentation is available at: https://ripe67.ripe.net/presentations/210-CZ.NIC_GEN6_ZuzanaDuracinska.pdf Alexander Isavnin, NetLine, noted that IPv6 adoption in Russia is very low and asked if the results Zuzana presented correlate with any European programs to deploy IPv6. Zuzana responded that in this particular case they have looked at GEN6. Inside the country they are also collaborating with many different organisations. But deployment in governments take a long, long time. Lee Howard, Time Warner Cable, thanked Zuzana for this presentation and said it was very useful. He mentioned that he would love to see collaboration to compare policies by country and to see which policy helps the most to encourage IPv6 deployment. One effort is to show that access to IPv4 is getting more expensive. Zuzana answered that people have to realise that it is not just about websites. There are going to be more and more online services and we won't be able to do it without IPv6. There were no further questions. E. Case Study: An ISP IPv6 Addressing Plan - Yannis Nikolopoulos, OTE The presentation is available at: https://ripe67.ripe.net/presentations/222-ripe67-yanodd-ipv6-addressing.pdf Shane Kerr, ISC, commented that he felt the study was very interesting in concept and noted that it was somewhat similar to the proposal made by Peter Lothberg in the first IPv6 session. Yannis responded that he was afraid to mention the similarity. Shane noted that Yannis had different goals and usage of the bits when compared to Peter Lothberg, but noted that the basic idea of encoding information other than raw topology and aggregation into the address was quite interesting. Shane continued that the IPv6 Working Group does not have the tools to evaluate this, so proposed moving it to the list. Yannis agreed, commenting that he was going to propose moving it to the list, too. Shane responded that this was normal procedure, and hoped that there would be good consensus in that this kind of experimentation is the way forward. Marco Hogewoning agreed that this would be followed up on the list. Rüdiger Volk, Deutsche Telekom Technik GmbH, commented that he was guilty of talking about using a few address bits in IPv6 for semantic purposes since the RIPE 50 Meeting in Stockholm. He continued to elaborate on his experiences in IETF when this kind of address usage is presented and leads to complaints from senior architects. Rüdiger then commented that address space and bits should not be used for ‘administrative convenience’, or we would need IPv7 soon. He stated that if operational and forwarding semantics are very carefully defined to the bits, then too much space is probably not burnt up. In his opinion, this proposal went too far in the direction of administrative convenience. Marco stated that, as Shane had suggested, this would be taken up on the IPv6 Working Group Mailing List, and thanked Yannis for his presentation and flexibility in scheduling. There were no further questions. F. Small Scale Redundant IPv6 Uplinks without BGP Benedikt Stockebrand, Stepladder IT The presentation is available online at: https://ripe67.ripe.net/presentations/249-presentation.pdf Tore Anderson, Redpill Linpro, stated that, in his organisation, they are doing something that solves the problem in a simpler way than any of the solutions offered. They are getting a provider-independent (PI) block, for the end user, but are not running BGP to the user – simply originating the prefix for them, as does ISP B. This way, these parties don’t need to learn BGP, but have stable addressing and if the link from their downstream interface to the customer goes down, the route disappears from their IGP, and they can immediately stop announcing it to the world and so does ISP “B”. So if they want to force the traffic, the customer can just shut down the interface and it will automatically converge. He stated that they had been doing this in IPv4 as well as in IPv6 for several years. Benedikt responded that this would be very expensive, due to the extra routes in the default-free zone; other people would pay the bill for this because they would need to pay for the extra memory. The attendee responded that this is the case with IPv4 PI space and that is what the IPv6 community has agreed to allow. Benedikt stated that this was correct, but commented that everything is getting larger – the default-free zone, the routing tables – faster than we can keep up with, in terms of extra memory, larger routers and highly reliable network connectivity. He stated that he doesn’t expect this to work in the long run. The attendee pointed out that IPv6 PI graphs are shown at every address policy meeting and these show no explosion of IPv6 PI. Benedikt argued that once people start using IPv6 as much as IPv4, then he felt we would probably see that increase. Marco Hogewoning directed both Benedikt and the attendee to continue their discussion on the mailing list. Mikael Abrahammson, T-Systems, commented that he had been doing the same thing as Benedikt for a couple of years with two uplinks, and that it works really well. He commented that they need something automatic to make it work, which is basically an IPv6 tunnel broker. He commented that they could have it as a third party as well, and it could be anyone. He added that he would also like to see end hosts partaking in multipath TCP or SHIM6, and stated that he felt this is the way they need to go, long-term, to work without cludges. Benedikt responded that he wasn’t sure, and we will see about SHIM 6. He conceded that it’s a problem with the locator identifier. Mikael replied that the only way this will scale long-term is with a kind of mechanism where the end-host has multiple addresses for ISPs and can then choose. Gert Doering, SpaceNet AG, added that they have discussed this, but for the sake of the audience he was bringing about another point of view: it would work and it’s good to save some global routing slots, so there is a definite benefit to this method. He then stated that he thinks it’s overdoing it, because what you gain from it is session survivability if one of the ISPs goes down. He stated that he has been convinced that most sessions, for the standard end users as opposed to the people in the room, are so short that, if an ISP goes down, they just click reload in their browser and the problem is solved. He therefore thinks the market for something so complex is small; however, at the same time, we need to be working on teaching applications to handle multiple sources better, and to handle the failure of a single source address better. He added that this is “dark matter” at the IETF he noted that this is not specified at all. Marco commented that when he asked Benedikt the question that helped inspire the presentation, he was commenting about small or medium-sized business becoming redundant, as opposed to end users. However, he noted that if you fit your house with sensors, it may become beneficial to run this at a Homenet. Benedikt added that Marco’s concern was that, in some countries where there is a national firewall, for example, maintaining a session may be helpful. There were no further questions. G. IPv6 Source Address, What Could Possibly Go Wrong? - Jen Linkova, Google The presentation is available online at: https://ripe67.ripe.net/presentations/288-Jen_RIPE67.pdf Marco Hogewoning asked whether, on the site local, Jen thinks this is because it’s deprecated, or old installations, or old books. Jen responded that some people probably chose them being unaware of them becoming deprecated, while looking for private addresses for IPv6, and did not pay enough attention to the differences between UL and site local. On her site local slides, she sees plenty of ICMP packets and stated that maybe some people were using them for infrastructure links – and maybe there are some other explanations. Marco commented that it may be useful for those doing IPv6 training to spend more time on this. Benedikt Stockebrand stated that he may have some explanation for some of the “weird” stuff. He stated that people have taken him aside and told him they have added IPv6 support as far as they could, but never got a chance to test it (due to managerial constraints). Therefore, Benedikt believes that maybe there’s a chance some software out there was only tested with IPv4 but that developers tried to implement IPv6 within it – but could never test it properly. Benedikt stated that it may be interesting to see if the “weird stuff” changes in the future. Jen agreed that she could check the numbers, compare the two years and look at the difference. Benedikt commented that it would perhaps be interesting because he thinks there are more people who tried to make IPv6 functional when they didn’t know what they were doing and the software is therefore out there, but for IPv4 only. Marco wondered whether it would be worth cooperating with the MAT Working Group and expand this type of measurement into something more long-running. Jen stated that she would have a discussion with Google’s security group because she basically did firewall filtering and just collected everything. Marco added that it may be worth looking at different pick-up points other than google.com and that it would be interesting to see how it changes over time. There were no further questions. H. Moving on…IPv6, DS-Lite and PCP Anastasios Chatzithomaoglou, Forthnet The presentation is available online at: https://ripe67.ripe.net/presentations/287-Tassos_Chatzithomaoglou_-_Moving_… Rumy Kanis, RIPE NCC, asked a question as chat monitor on behalf of an unnamed participant. The participant asked whether Tassos had experienced any issues with path MTU discovery on IPv4 when they run it over DS-Lite. Tassos responded that they had a lot of issues until they solved it with IPv4 and the CPE initially when they started testing. That was one year ago, it was resolved and then every CPE that tested had their own MTU so they had a lot of issues there. The issues were resolved. Rumy asked a combined question from Ole Troan, IETF, and Mark Townsley, Cisco, via the chat room. They didn’t understand why DS-Lite was cheaper than NAT 444, both having centralised CGN with a similar amount of state, and wondered whether Tassos had calculated the cost of moving the net state to the CPE, as in running “A plus B”. Tassos responded that they hadn’t calculated that until now, but were evaluating that. He continued that, as IPv6 traffic increases, they have lower traffic from the CGN, so instead of having the whole subscriber traffic passing through the CGN in the 444 solution, they only pass the actual IPv4 traffic. So in the future, when they reach 50% of IPv6 traffic, the CGN load will only be 50% because half the traffic will be outside the CGN. It will become cheaper over time. Rumy commented that it is the same as with dual stack. Tassos agreed, but noted that they don’t have any cost on the dual stack side. There were no further questions. I. Exchange of Feedback on Running an IPv6 Only LAN at the RIPE Meeting - Marco Hogewoning, IPv6 Working Group Chair and Andrew Yourtchenko, Cisco The presentation is available at: https://ripe67.ripe.net/presentations/129-IPv6-WG-2.pdf Marco Hogewoning began, stating that it was RIPE 37 in September 2000 when the first IPv6 network was available at a RIPE Meeting. He said he and Andrew felt it was time for the next step – running an IPv6-only network. He emphasised that it was not supported by the RIPE NCC technical team, was a voluntary effort, and done on a best-effort basis. Marco proceeded to thank Cisco for their gear and manpower, and Andrew Yourtchenko specifically. Marco acknowledged that while the RIPE NCC technical team didn’t officially support the endeavor, they did put in effort to ensure that the network was running, and thanked the team. Marco stated that they had a “wholesale” model – the RIPE NCC provided them with an SSID that was running on the normal frequency map, and delivered all the traffic to them, where they pumped it into a Cisco AS RIK, which they borrowed, and had an uplink to the RIPE Juniper in between. The uplink to the Juniper was dual stacked, the site towards the wireless was entirely IPv6 only, and since they were running Net 64, they also needed the DNS server. They bought a server in the form of an old Macbook running virtual servers, and that was all dual stacked. He said it was a simple setup, all wires, and no VLANs or anything else to complicate matters. Marco explained that it was switched on Sunday, and they slowly made it work. Traffic was not particularly large apart from one big spike of 24 megabits. He said the number of clients was somewhat small, but on Tuesday afternoon they saw between 30 and 50 clients online all the time. Marco added that he is aware that the average number of devices at RIPE Meetings is about 700, so he thinks approximately 5% of the attendees at the session had tried it. As far as incidents are concerned, he said there was one failure on Monday afternoon, after the IPv6-only network was announced in the plenary. A faulty patch cable fell out of the laptop server, and without DNS etc., everything shut down. Andrew rushed up to repair it. Other than that, they attempted imprecise network monitoring. Twitter was busy, using NAT 64. There was a hashtag which invoked a lot of response, and the operators of the IPv6-only network were grateful for the feedback. Facebook supported IPv6 on the website, but didn’t on their apps. They also tried using the mailing list, and discovered that if you have an iPad, you couldn’t get your mail over an IPv6-only network. Some feedback was that users encountered a failure called IP 101 when trying to reset a Cisco password. Andrew Yourtchenko took the floor, stating that this is not specific to IPv6-only, and is the reason why people should enable IPv6 on the website now rather than later. It had slipped past the testing as they were dual stacking a bunch of back-end servers a month or so ago, and the percentage of users is relatively low. They discovered it after all the paperwork had been completed and everything had been “lit up” so they decided to keep IPv6 on the server in spite of this. He said the good news is that they are working on this, and hopefully would have more news the next day. Regarding DNS issues, a lot of people use the operating systems that don’t support getting DNS, either by stateless DHVP v4, or RA. He said manual configuration was needed, which is awkward with IPv6 addresses. He had conducted a speed test on Sunday, and IPv4 over IPv6 still came out faster than IPv6. He said the good news was that it was isolated to a specific server (in the Netherlands), but Andrew thinks there is still work to do there. Andrew commented, regarding Aerohive Manager, that there were many “unknown operating systems” detected. The detection mechanisms in the management systems, therefore, still need to catch up. He said the interesting thing was that the number of clients when measured as a sum of 2.4 and 5 Ghz clients is bigger than the number of clients as measured by the operating system detection, and this should normally be the same number. There are clients by operating system, and clients by radio – and when it doesn’t add up, some clients are in “limbo”. Andrew believed that these are probably the people who switched off IPv4 completely and then the management doesn’t know how to deal with it. Andrew asked the attendees how many people used only IPv6 during this conference. After a show of hands, he concluded that it was around the 30 addresses that they saw in the conference. He thanked those using it. He invited the attendees to give feedback, and asked whether they would try this in their own networks. Patrick Falstrom, Netnod, commented that he was running the wireless network at a social media conference in Sweden, attended by people who were not particularly technically minded. Even so, Patrick ran an IPv6-only network and it was still very interesting, and attendees were very appreciative. He commented that Twitter didn’t have a good IPv6 experience. He felt it was particularly interesting to run this in an environment where people did not know much about IPv6 or networking. Jen Linkova, Google, thanked Marco and Andrew, commenting that it was a very interesting experience that should definitely be repeated. She switched to IPv4 twice – to change her Cisco password, and to change the VPN. However, she stated that she used IPv6 most of the time and it’s good that all applications could be tested, besides Facebook and Twitter. Marco stated that the RIPE NCC corporate VPN became unstable while working over the IPv6-only network, so he switched back to the regular network in order to keep accessing emails. Gert Doering, SpaceNet AG, spoke up that it was not the first time an IPv6-only had been attempted , and that it had been enacted in Berlin with great success, so it should be a regular service for every RIPE Meeting. Marco commented that he would relay this to the meeting organisation team to see what they could do. However, he recalled that in Berlin the network went down. Gert acknowledged that it worked much better this time than it had in Berlin, and commended Marco and Andrew on a job well done. He referred to Berlin as an experiment, stating that now they know how to run it. An unnamed attendee remarked about the Net 64 prefix. He asked why the documentation prefix was used. Andrew responded, attributing this simply to laziness. He said he used the well-known prefix in some cases, where the addresses were RFC 1918. The standard prohibits the use of the well-known prefix, so, in that instance, he quickly hacked into something else. The speaker responded that it was about time the recommendation gets sent to Google. Andrew responded that it doesn’t get sent. Marco asked which of the attendees had discovered something that didn’t work and fixed it. He noted one attendee raising their hand. Marco stated that part of the purpose of this experiment was to find out what doesn’t work and fix it. David Kessens, IPv6 Working Group co-Chair, closed the session, thanking the attendees and inviting them to spend time on the IPv6-only network. Marco added, as a concluding comment, that everything related to IPv6 is welcome on the IPv6 Working Group Mailing List, not just policy-related issues.

5 6

RIPE-554, it is time for an update
by Sander Steffann 11 Apr '14

11 Apr '14

Hi WG, The authors of RIPE-554 have received suggestions for improving RIPE-554 over the years. Because we didn't want to publish a new document every couple of months (new document = new number = more confusion among users than it is worth) we just collected them. And now, almost 2 years after RIPE-554 was published, we think it is time to work on the next version! So, IPv6 WG, what would you like to see changed in RIPE-554? More/less explanatory text, more device types, adding or removing certain RFCs etc etc etc? Please let us know! To the WG chairs: can you please provide us with a slot at RIPE 68 so we can discuss this topic there? Cheers, Sander

4 5

IPv6 troubleshooting procedures for helpdesks
by Jan Zorz ＠ go6.si 11 Apr '14

11 Apr '14

Dear IPv6 WG, As presented at BCOP BoF at last meeting in Athens, we finished the 00 version of the draft of the document titled "IPv6 troubleshooting for helpdesks". Initial Co-authors: Lee Howard, John Jason Brzozowski, David Freedman, Jason Fesler, Tim Chown, Sander Steffann, Chris Grundemann, Jan Žorž Short description: “IPv6 troubleshooting for helpdesks” is a community BCOP document, intended to provide a starting point for technical support staff at ISPs or enterprise IT helpdesks in supporting IPv6. Problems with IPv6 are very rare, but fear of the unknown has prevented or delayed many organizations from rolling out IPv6 to their users, when all technical problems have been solved. While this document cannot encompass all possible problems, it should provide a solid first step for front-line support personnel. You can find the first draft (and all following drafts in the future) here: http://go6.si/ipv6-troubleshooting-for-helpdesks/ Find the link to PDF at the bottom of the text and also the PDF attached. All comments, suggestions and ideas are (as always) more than welcome. BCOP TF is aiming to bring together the operators to write and document the best current *operational* practice and cooperate with various RIPE WGs to get the feedback and work on technical validity of the documents. This one is IPv6 related, therefore we asked the IPv6 WG chairs to cooperation and getting the work done in this working group. If you would like to join the authors working-forces forming, please join us at BCOP TF meeting on Monday evening after the Plenary agenda finishes and maybe even subscribe to the mailinglist. http://www.ripe.net/ripe/groups/tf/best-current-operational-practices-task-… https://www.ripe.net/mailman/listinfo/bcop Cheers and see you in Warsaw, Jan Zorz

1 0

New on RIPE Labs: Report on IPv6 Security Test Methodology
by Mirjam Kuehne 10 Apr '14

10 Apr '14

Dear colleagues, The Dutch institute for applied scientific research (TNO) and a number of Dutch security companies have recently published a report on IPv6 security test methodologies. Please find a summary on RIPE Labs: https://labs.ripe.net/Members/geert_jan_de_groot/report-on-ipv6-security-te… Kind regards, Mirjam Kuehne RIPE NCC

1 0

Re: [ipv6-wg] I thought e-mail over IPv6 was easy
by Geert Jan de Groot 10 Apr '14

10 Apr '14

> I saw the headline for this article and thought, "wtf, e-mail just > worked over IPv6 from the time I put the AAAA record in the DNS". But I > went ahead and had a look, and it is actually pretty interesting: > http://engineering.linkedin.com/email/sending-and-receiving-emails-over-ipv6 Actually, it's even more complicated than that. I need to send mail directly instead of "use the provider relay" because the provider relay doesn't allow me to check whether mail is still queued - not all the world has reliable mail delivery, unfortunately and for the people I work with, this is an issue. For IPv4, it's easy for an ISP to set up stub forward & reverse records and that's what I got away with for many, many years. For IPv6, the situation is different. As discussed, users have more than one address and hence may need need more than one forward/reverse pair, and the address may not be predictable. This gives new problems: * If the connection is big enough to warrant delegation, then making FCrDNS work for IPv6 is doable. For small businesses and home power users however, this may not be feasible. * Making forward & reverse match for every /48 of every customer is a challenge; * Delegating may not be feasible. How do you delegate to "John's pet animal and sushi shop"? The guy probably doesn't run a DNS server to delegate to.. * Making Dynamic DNS updates work between ISP and customer is a challenge at best; * I have not seen any portal solutions, to let the customer handle this. Even with XS4all, for whom I am a customer, doesn't have an automated way for this and the current workaround involves manual intervention with all it's nasty scaling properties. * I don't think that customer-specific subdomains and SPF-records will scale either. I don't hear much of this new, IPv6-specific problem. Comments? Geert Jan

2 1

I thought e-mail over IPv6 was easy
by Shane Kerr 09 Apr '14

09 Apr '14

All, I saw the headline for this article and thought, "wtf, e-mail just worked over IPv6 from the time I put the AAAA record in the DNS". But I went ahead and had a look, and it is actually pretty interesting: http://engineering.linkedin.com/email/sending-and-receiving-emails-over-ipv6 Cheers, -- Shane

2 1

IPv6 Deployment in Access Networks, CFP
by Aleksi Suhonen 09 Apr '14

09 Apr '14

Hello, The Finnish Communications Regulatory Authority (ficora.fi) recently published recommendations for IPv6 adoption in consumer grade Internet connections. TREX hosts an annual seminar for ISPs. We're putting together the programme for this year's seminar[1] and we're trying to help Ficora in their push to get IPv6 on the map in Finland. [1] http://www.trex.fi/2014/seminar.html So I'm looking for presentations from ISPs that have already deployed IPv6 in their Internet access products. The presentations should be rather technical, but there should also be a section on lessons learnt and on future plans, if there are any. Another aspect that the presentations should highlight is what prompted the network wide upgrade and what benefits have been achieved. Yours filled with hope, -- +358 4567 02048 / http://www.trex.fi/ Aleksi Suhonen / TREX Regional Exchanges Oy You say "potato", I say "closest-exit."

2 1

[training] RIPE NCC Webinars - new dates
by Training Services 08 Apr '14

08 Apr '14

Dear colleagues, We are pleased to announce the launch of new dates for our Webinars. The RIPE NCC Webinars are live and take only one hour. You can interact with our trainers without leaving your desk. 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 <training(a)ripe.net>. We look forward to seeing you online. Kind regards, RIPE NCC Training Services

1 0

[training] RIPE NCC Webinars - new dates
by Training Services 25 Mar '14

25 Mar '14

Dear colleagues, We are pleased to announce the launch of new dates for our Webinars. The RIPE NCC Webinars are live and take only one hour. You can interact with our trainers without leaving your desk. 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 <training(a)ripe.net>. We look forward to seeing you online. Kind regards, RIPE NCC Training Services

1 0

[training] RIPE NCC Courses in Sofia, Bulgaria 16-17 April 2014
by Training Services 14 Mar '14

14 Mar '14

Dear Colleagues, The RIPE NCC Training Services Department invites you to register for our upcoming Training Courses in Sofia, Bulgaria: Course type: RIPE Database Training Course Date: Wednesday, 16 April 2014 Time: 09:00-17:30 Course type: IPv6 for LIRs Training Course Date: Thursday, 17 April 2014 Time: 09:00-17:30 How to register: ---------------- You can register up to two people from your LIR for each course by using the LIR Portal at: https://lirportal.ripe.net/training/courses Registration will close when maximum capacity is reached, so please register soon to ensure your attendance. The course is free of charge. We provide lunch and printed training materials. We do not cover any of your travel expenses or accommodation. We give all of our training courses in English. RIPE Database Training Course: ------------------------------ You should attend this training course if you are part of the staff of a Local Internet Registry (LIR) in the RIPE NCC Service Region. You can find more information about the course at: https://www.ripe.net/lir-services/training/courses/rdb IPv6 for LIRs Training Course: ------------------------------ You should attend this training course if you are part of the staff of a Local Internet Registry (LIR) in the RIPE NCC Service Region and if you: * Are thinking about deploying IPv6 in your organisation * Have been told you need to deploy IPv6 * Need to convince your manager that IPv6 needs to be deployed * Looked at an IPv6 address and thought it was too complicated to deploy in your network You can find more information about the course at: http://www.ripe.net/lir-services/training/courses/ipv6 If you have any questions, send an e-mail to <training(a)ripe.net>. Kind regards, RIPE NCC Training Services

1 0

[training] RIPE NCC Webinars - new dates
by Training Services 11 Mar '14

11 Mar '14

Dear colleagues, We are pleased to announce the launch of new dates for our Webinars. The RIPE NCC Webinars are live and take only one hour. You can interact with our trainers without leaving your desk. 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 <training(a)ripe.net>. We look forward to seeing you online. Kind regards, RIPE NCC Training Services

1 0

Call for topics/ideas for RIPE 68 (Warsaw)
by Marco Hogewoning 06 Mar '14

06 Mar '14

Dear colleagues, It is that time of the year again that we need to start thinking about the agenda for our meeting. The 68th RIPE Meeting will be held in Warsaw from 12 to 16 May. The draft meeting plan has the IPv6 Working Group scheduled for 2 sessions on the morning of Thursday 15 May. Please let us know asap if you which to present something, discuss something or have any other things you would like to see included on the agenda. We especially would like to encourage people with operational experience in running IPv6 towards customers to consider sharing their experience and knowledge for the benefit of those operators who are still facing the challenges of IPv6 deployment. Submissions can be made to ipv6-wg-chair [at] ripe [dot] net Thank you and hope to meet you all in Warsaw, Marco, David and Shane The co-Chairs of the IPv6 Working Group

1 0

Fwd: [address-policy-wg] IPv6 PA/PI - restarting discussion after failed 2013-06 proposal
by Elvis Velea 04 Mar '14

04 Mar '14

Hi everyone, I am forwarding this message to the IPv6-WG as well as it involves changes that I/we may propose to make to the IPv6 Policy. Please join the discussion and comment; however, I would like to kindly ask you to send your replies to the AP-WG for the ease of collecting the feedback. cheers, elvis -------- Original Message -------- Subject: [address-policy-wg] IPv6 PA/PI - restarting discussion after failed 2013-06 proposal Date: Tue, 04 Mar 2014 02:50:52 +0100 From: Elvis Daniel Velea <elvis(a)v4escrow.net> Organization: V4Escrow, LLC To: Address Policy Working Group <address-policy-wg(a)ripe.net> Hi everyone, 2013-06 has failed to become policy and we all understand that it presented such big changes that it became too complex. I would like to restart that discussion and see what are the problems/failures of the IPv6 policies (both PI and PA) and come up with a proposal to fix these problems. I'd like to start with the first 4 problems that I have noticed: #1. In IPv4 a PI user can connect a customer to it's network or allow a customer to use a dedicated server using one IP address. This limitation had been extended to up to a /29 (in case redundant connections were offered - ie:VRRP) but most of the cases I have encountered were using either a /32 or a /30. Currently, the IPv6 policy states that the minimum a customer should use is a /64. And because the minimum per customer is a /64, when someone would actually use IPv6 PI for a customer, it would make an assignment of a subnet and violate the policy. I've heard of people using /128s for the servers of their customers and sharing the same vlan amongst multiple customers in the same /64. Others are just requesting a/48 PI and expect never to come back for more (therefore, could not care less about policies). Others just know that the RIPE NCC has no way to see if they sub-assign parts of the /48 PI, so they just request a /48 PI, promise never to sub-assign and later on, forget about the promise. Therefore, I propose that the first change we make to the IPv6 PI policy is that where a /64 could be used per customer (regardless of the service offered to that customer) only if it is registered properly in the RIPE Database. The change would allow PI users to sub-assign in IPv6, but only small (?) amounts of space and only if they actually register the assignment. #2. Second problem I've noticed is the fact that LIRs can receive /32s (and up to /29s) only by asking. On the other hand, if you do not want to become a RIPE NCC member or just can not, you are forced to use IPv6 - a /48. Additionally, this IPv6 PI can only be used for your own infrastructure and not to provide any service (other than SaaS) to your customers without violating the policy (see problem statement #1). One could request more than a /48 but it would need to demonstrate that it has two or more sites that have different routing policies or demonstrate that it has a need for more than 65K subnets. I would like to introduce the IPv6 PI ALLOCATION. This time, the PI allocation could be made to the PI user and the user could actually make assignments from it. The PI allocation would be just as large as the PA Allocation and the price for it would be no less than 50% of the membership fee (Off course, the fees can only be voted upon at the GM and the example is just purely theoretical). This would introduce that 'additional registry' which we never knew how to name during the discussions of 2013-06 and would allow PI users to request/receive a /29 from which they could make assignments. Everyone will say that /32 or /29 will become the new /48. Well, that may be true, on the other hand, it may be the price that could keep the number of large PI Allocations low. Additionally, we could add an arbitrary limit. For example, say that you can request an IPv6 PI Allocation only if you already have x hundred customers that will receive an assignment from you immediately. #3. Minimum assignment size The policy says that the minimum assignment size is a /64. However, the RIPE Database does not enforce this rule and I have seen /128s registered. for example: inet6num: 2001:b70:f000::/112 inet6num: 2001:820:0:1:1::1000/116 inet6num: 2a01:2f0f:ffff:ffff:100:1000::1/128 There are over 700 inet6num objects registered which are below a /64. If we take the policy literally, all these assignments currently violate the policy. Therefore, I think we should either change/remove the minimum assignment size or have the RIPE Database block the creation of any IPv6 assignment smaller than a /64. #4. fix utilisation and hd-ratio vs assignment size While the HD-ratio is being calculated in terms of /56s, the policy says (at point 5.4.1.) that the minimum assignment that can be made is a /64. Furthermore, as you can see above, /128s can be registered in the RIPE Database as well. If we will continue allowing the registration of less than /56 assignments, it will be difficult to almost impossible to the IPRAs to actually calculate what is the HD-ratio of an IPv6 allocation. While now it is too early to see additional IPv6 allocation requests, if we keep doing things as we've been doing for the past years, we will end up in a few years with a huge mess in the registry and the impossibility to calculate the HD-ratio without applying random procedures. A very simple and quick fix would be to say that if any prefix is registered, the whole /56 that includes the prefix is in use. But then, we may see people registering/using /128s from different /56s just to reach the HD-ratio for an additional allocation. Would that still be considered an efficient usage? An other option would be to change the HD-ratio calculation to the actual number of IP addresses used and consider all the IP addresses from an assignment used if correctly registered in the RIPE Database. Once we have worked out whether these 4 issues are indeed flaws in the policy or not and whether we want them fixed or not, I would like to hear your opinion in what else should be modified in the IPv6 policies. I will then collect all the feedback, probably present it at the next RIPE Meeting, and start to discuss an other approach/policy proposal to achieve what 2013-06 failed to achieve. cheers, elvis -- <http://v4escrow.net> Elvis Daniel Velea Chief Business Analyst Email: elvis(a)V4Escrow.net <mailto:elvis@v4escrow.net> US Phone: +1 (702) 475 5914 EU Phone: +3 (161) 458 1914 Recognised IPv4 Broker/Facilitator in: This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received this email in error, please notify the sender immediately and delete the original.Any other use of this email is strictly prohibited.

1 0

[training] RIPE NCC Webinars - new dates
by Training Services 25 Feb '14

25 Feb '14

Dear colleagues, We are pleased to announce the launch of new dates for our Webinars. The RIPE NCC Webinars are live and take only one hour. You can interact with our trainers without leaving your desk. 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 <training(a)ripe.net>. We look forward to seeing you online. Kind regards, RIPE NCC Training Services

1 0

[training] RIPE NCC Training Courses April-June 2014
by Training Services 18 Feb '14

18 Feb '14

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 St. Julian's, Zagreb, Sofia, Brussels, Edinburgh, Tehran, Helsinki, Moscow, Kiel, Almaty, Reykjavik, Geneva. 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 - IPv6 for LIRs Training Course - Routing Security Training Course - 3 day Deploying IPv6 Training Course (New) - DNSSec Training Course (New) For more information visit: https://www.ripe.net/lir-services/training/courses With kind regards, Rumy Spratley-Kanis Training Services Manager

1 0

[training] RIPE NCC Webinars - new dates
by Training Services 11 Feb '14

11 Feb '14

Dear colleagues, We are pleased to announce the launch of new dates for our Webinars. The RIPE NCC Webinars are live and take only one hour. You can interact with our trainers without leaving your desk. 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 <training(a)ripe.net>. We look forward to seeing you online. Kind regards, RIPE NCC Training Services

1 0

Fwd: RACI @ RIPE 68 - Opportunity for Students and Researchers
by Marco Hogewoning 23 Jan '14

23 Jan '14

If you are or know somebody doing research that is somewhat Internet related (doesn’t have to be IPv6 :). RIPE NCC has again put a call out for applicants to the RACI programme. And I am sure that I can speak for my fellow chair that we are happy to consider any IPv6 related material for inclusion in our work group. MarcoH (in his role as co-chair of this working group) > Dear colleagues, > > The RIPE Academic Cooperation Initiative (RACI) is providing a number of > students and researchers the opportunity to participate at RIPE 68 in > Warsaw from 12-16 May. We are offering packages that include meeting > registration and paid travel and accommodation, and we are currently > seeking applications from across the RIPE NCC service region. > > We would like to ask for your assistance to raise awareness of the RACI > program. Many in the RIPE community have strong connections with > academic institutions, and we are keen to make those institutions and > their students aware of this great opportunity. > > RACI gives students and researchers the opportunity to present their > work in front of some the leading technical figures in the Internet > world, receive feedback on their research from experts and have their > work published on the RIPE Labs website for community feedback. The RACI > program also benefits the RIPE community by introducing newer members to > the community who can give interesting presentations at RIPE Meetings > that might not otherwise be seen. > > The initiative is coordinated with the RIPE Programme Committee to allow > the RACI participants to present their research, either during > plenary/working group sessions, or in lightning talks at other > designated sessions. > > Students and researchers may wish to present on any topic relevant to > the RIPE community, including (but not limited to): > > - Network measurement and analysis > - IPv6 deployment > - BGP routing > - Network security > - Internet governance > > Students and researchers who are interested in RACI sponsorship can fill > out the application form on the RIPE 68 webpages: > https://ripe68.ripe.net/programme/raci/application/ > > All applications must be received by Friday, 25 April 2014. Applicants > will be informed about the status of their application by Friday, 2 May > 2014. Any applications received after 25 April 2014 will be considered > for RACI at RIPE 69, to be held in London from 3-7 November 2014. > > More information on RACI is available at: > https://ripe68.ripe.net/programme/raci/ > > Best regards, > > The RACI Coordination Team > RIPE NCC

1 0

[training] RIPE NCC Webinars - new dates
by Training Services 20 Jan '14

20 Jan '14

Dear colleagues, We are pleased to announce the launch of new dates for our Webinars. The RIPE NCC Webinars are live and take only one hour. You can interact with our trainers without leaving your desk. 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 <training(a)ripe.net>. We look forward to seeing you online. Kind regards, RIPE NCC Training Services

1 0

RIPE 554 Errata Page
by Wilhelm Boeddinghaus 17 Jan '14

17 Jan '14

Dear colleagues, as shortly discussed in Dublin I suggest to set up an errata page for the RIPE 554 document. Errors have been found, and we cannot change anything in the document without getting a new RIPE document number. But having to many different versions of the document confuses our audience. A errata page would make it possible to document minor but important changes of the content of the document. If the group says "yes" we could ask RIPE to help with a page like this. It should be easily reachable from the download page of RIPE554. Kind regards, Wilhelm Boeddinghaus

15 33

New on RIPE Labs: How Many RIPE Atlas Probes Can Resolve IPv6-only Domain Names?
by Mirjam Kuehne 13 Jan '14

13 Jan '14

Dear colleagues, Please find a new article on RIPE Labs submitted by Stéphane Bortzmeyer: How Many RIPE Atlas Probes Can Resolve IPv6-only Domain Names? https://labs.ripe.net/Members/stephane_bortzmeyer/how-many-ripe-atlas-probe… Kind regards, Mirjm Kuehne RIPE NCC

1 0

Follow up on RIPE67 IPv6 Only experiment
by Marco Hogewoning 10 Jan '14

10 Jan '14

Dear colleagues, Just to let you know that, based on experience in Athens, I put up a blogpost on Circle-ID about running IPv6 only. http://www.circleid.com/posts/20131212_are_we_ready_to_switch_off_ipv4/ Would also love to hear from you wether we should aim to repeat this experiment in Warsaw. Or maybe you have an idea of something else that you think is worth trying, please let us know. Best, MarcoH -- "Life is like riding a bicycle. To keep your balance you must keep moving" -- Albert Einstein

8 9

[training] RIPE NCC Webinars - new dates
by Training Services 06 Jan '14

06 Jan '14

Dear colleagues, We are pleased to announce the launch of new dates for our Webinars. The RIPE NCC Webinars are live and take only one hour. You can interact with our trainers without leaving your desk. 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 <training(a)ripe.net>. We look forward to seeing you online. Kind regards, RIPE NCC Training Services

1 0

Re: [ipv6-wg] ipv6-wg Digest, Vol 27, Issue 4
by behroz abbaszadeh 20 Nov '13

20 Nov '13

Dear Marco thank you very much, Is it possible to upload some documents of this meeting like PDF format of presentations and ... Cheers Behrouz ________________________________ From: "ipv6-wg-request(a)ripe.net" <ipv6-wg-request(a)ripe.net> To: ipv6-wg(a)ripe.net Sent: Wednesday, November 13, 2013 2:30 PM Subject: ipv6-wg Digest, Vol 27, Issue 4 Send ipv6-wg mailing list submissions to ipv6-wg(a)ripe.net To subscribe or unsubscribe via the World Wide Web, visit https://www.ripe.net/mailman/listinfo/ipv6-wg or, via email, send a message with subject or body 'help' to ipv6-wg-request(a)ripe.net You can reach the person managing the list at ipv6-wg-owner(a)ripe.net When replying, please edit your Subject line so it is more specific than "Re: Contents of ipv6-wg digest..." Today's Topics: 1. Re: 14th Saudi Arabian Task Force Meeting (Erika.Hersaeus(a)pts.se) ---------------------------------------------------------------------- Message: 1 Date: Tue, 12 Nov 2013 17:53:08 +0000 From: <Erika.Hersaeus(a)pts.se> Subject: Re: [ipv6-wg] 14th Saudi Arabian Task Force Meeting To: <marcoh(a)ripe.net>, <ipv6-wg(a)ripe.net> Message-ID: <F9B35F1FF22AED4B9198995E2F969B801D2F6596@maildb01> Content-Type: text/plain; charset="iso-8859-1" Marco, Thank you very much for the report! Greetings, Erika -----Ursprungligt meddelande----- Fr?n: ipv6-wg-bounces(a)ripe.net [mailto:ipv6-wg-bounces@ripe.net] F?r Marco Hogewoning Skickat: den 11 november 2013 14:13 Till: ipv6-wg(a)ripe.net IPv6 ?mne: [ipv6-wg] 14th Saudi Arabian Task Force Meeting [a copy of this report will also be made available on http://labs.ripe.net/] Dear Colleagues, The RIPE NCC recently participated in a meeting of the Saudi Arabian Task Force. A well-attended event, it included presentations and discussions about IPv6 deployment strategies, as well as presentations by operators reporting back on their successful IPv6 pilot projects and plans to roll out IPv6 in the first half of 2014. The 14th Saudi Arabian Task Force Meeting, was held on November 7th, 2014 in Riyadh. This successful event, hosted by the Communication and Information Technology Commission (CITC), had over 40 participants from the Saudi Arabian Internet Industry as well as representatives from government institutions and enterprises, discussing the deployment of IPv6. The meeting was preceded by a three-day MENOG IPv6 Roadshow. 21 participants took part in this technical training, learning how to configure and deploy IPv6 in their networks. Dr Ibraheem Al Furaih (CITC), in his presentation, highlighted the fact that the number of Internet users in Saudi Arabia is still rapidly growing, surpassing 16.5 million in the first half of 2013. With the global and regional IPv4 address pool depleted, a rapid deployment of IPv6 is necessary in sustaining future growth and to enable the remaining 45% of the population to also connect to the Internet. He also announced that, following the decision of the Task Force to put more focus on enterprise networks, CITC will run a pilot in which four enterprises will be supported in enabling IPv6 on all their customer-facing services. Ashraf Sattar (STC) reported back on a successful pilot project in enabling IPv6 on their DSL network. With the tests completed, they expect to begin rolling out IPv6 as a production service in the first quarter of 2014, followed by a planned deployment of IPv6 in the FTTH network in the second quarter. He also highlighted some of the design challenges that mobile operators are facing, concluding that a single stack approach, in which an IPv6-only service is complemented by an IPv6 to IPv4 translation service, is the most promising solution. However, as he remarked, such a solution would put limits on the peer-to-peer communication in between hosts. Motaz Alturayef (Mobily) provided the attendees with an overview of some of the security challenges in deploying IPv6. But as he mentioned, the fact that a lot of devices and software now have IPv6 capabilities, also poses a threat in that IPv6 traffic might escape to the attention of the security teams and intrusion detection systems. Amer Mustafa (GAMA) presented on the successful projects they did with several of their customers. Their segmented approach that focusses on different parts of the organisation allows for the deployment of IPv6 in only 90 days. He stated that convincing the business executives and decision makers was the biggest challenge in the fast deployment IPv6. A presentation by Marco Hogewoning (RIPE NCC) showed statistics about the deployment of IPv6 in Saudi Arabia taken from the various measurement programs, comparing them to those of other countries in the Middle East region, as well as to the global deployment statistics. He also highlighted that, while the IPv4 pool is depleted, there is still an ongoing need in maintaining the registration data of IPv4 resources to be accurate and complete. Gert Doering in his role as IPv6 Consultant explained the various options available within the RIPE NCC Service Region for obtaining IPv6 resources. Using several examples, he highlighted some of the drawbacks and benefits of those options for companies of various sizes. He invited the participants to take part in discussions in the RIPE Address Policy Working Group, which have been addressing several potential changes to IPv6 and IPv4 address policy. In conjunction with the IPv6 events, the RIPE NCC also invited its Saudi Arabian members, together with other stakeholders, for an informal dinner to discuss ongoing issues and the needs of the membership. The attendees expressed the need for further activities in IPv6 training, not only on a technical level but also for executive-level employees. They also welcomed the continued efforts made by the RIPE NCC to increase its presence in the Middle East, noting the expansion of the Dubai office to include more staff. All the presentations, as well as more information about the Saudi Arabian IPv6 Task Force, are available on their website, via http://www.ipv6.sa./The next meeting of the Task Force is planned to take place in April or May 2014. If you have any questions regarding this event or would like RIPE NCC staff to contribute to your IPv6 events please contact us via ipv6actnow [at] ripe [dot] net On behalf of the RIPE NCC External Relations Team, Marco Hogewoning End of ipv6-wg Digest, Vol 27, Issue 4 **************************************

2 1

[training] RIPE NCC Training Courses January-March 2014
by Training Team 19 Nov '13

19 Nov '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 Lisbon, Frankfurt, Busto Arsizio, Manamah, St. Petersburg, Tallinn, London, Warsaw, Copenhagen, Amsterdam, Bucharest. 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 - RIPE Database Training Course - 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

14th Saudi Arabian Task Force Meeting
by Marco Hogewoning 12 Nov '13

12 Nov '13

[a copy of this report will also be made available on http://labs.ripe.net] Dear Colleagues, The RIPE NCC recently participated in a meeting of the Saudi Arabian Task Force. A well-attended event, it included presentations and discussions about IPv6 deployment strategies, as well as presentations by operators reporting back on their successful IPv6 pilot projects and plans to roll out IPv6 in the first half of 2014. The 14th Saudi Arabian Task Force Meeting, was held on November 7th, 2014 in Riyadh. This successful event, hosted by the Communication and Information Technology Commission (CITC), had over 40 participants from the Saudi Arabian Internet Industry as well as representatives from government institutions and enterprises, discussing the deployment of IPv6. The meeting was preceded by a three-day MENOG IPv6 Roadshow. 21 participants took part in this technical training, learning how to configure and deploy IPv6 in their networks. Dr Ibraheem Al Furaih (CITC), in his presentation, highlighted the fact that the number of Internet users in Saudi Arabia is still rapidly growing, surpassing 16.5 million in the first half of 2013. With the global and regional IPv4 address pool depleted, a rapid deployment of IPv6 is necessary in sustaining future growth and to enable the remaining 45% of the population to also connect to the Internet. He also announced that, following the decision of the Task Force to put more focus on enterprise networks, CITC will run a pilot in which four enterprises will be supported in enabling IPv6 on all their customer-facing services. Ashraf Sattar (STC) reported back on a successful pilot project in enabling IPv6 on their DSL network. With the tests completed, they expect to begin rolling out IPv6 as a production service in the first quarter of 2014, followed by a planned deployment of IPv6 in the FTTH network in the second quarter. He also highlighted some of the design challenges that mobile operators are facing, concluding that a single stack approach, in which an IPv6-only service is complemented by an IPv6 to IPv4 translation service, is the most promising solution. However, as he remarked, such a solution would put limits on the peer-to-peer communication in between hosts. Motaz Alturayef (Mobily) provided the attendees with an overview of some of the security challenges in deploying IPv6. But as he mentioned, the fact that a lot of devices and software now have IPv6 capabilities, also poses a threat in that IPv6 traffic might escape to the attention of the security teams and intrusion detection systems. Amer Mustafa (GAMA) presented on the successful projects they did with several of their customers. Their segmented approach that focusses on different parts of the organisation allows for the deployment of IPv6 in only 90 days. He stated that convincing the business executives and decision makers was the biggest challenge in the fast deployment IPv6. A presentation by Marco Hogewoning (RIPE NCC) showed statistics about the deployment of IPv6 in Saudi Arabia taken from the various measurement programs, comparing them to those of other countries in the Middle East region, as well as to the global deployment statistics. He also highlighted that, while the IPv4 pool is depleted, there is still an ongoing need in maintaining the registration data of IPv4 resources to be accurate and complete. Gert Doering in his role as IPv6 Consultant explained the various options available within the RIPE NCC Service Region for obtaining IPv6 resources. Using several examples, he highlighted some of the drawbacks and benefits of those options for companies of various sizes. He invited the participants to take part in discussions in the RIPE Address Policy Working Group, which have been addressing several potential changes to IPv6 and IPv4 address policy. In conjunction with the IPv6 events, the RIPE NCC also invited its Saudi Arabian members, together with other stakeholders, for an informal dinner to discuss ongoing issues and the needs of the membership. The attendees expressed the need for further activities in IPv6 training, not only on a technical level but also for executive-level employees. They also welcomed the continued efforts made by the RIPE NCC to increase its presence in the Middle East, noting the expansion of the Dubai office to include more staff. All the presentations, as well as more information about the Saudi Arabian IPv6 Task Force, are available on their website, via http://www.ipv6.sa. The next meeting of the Task Force is planned to take place in April or May 2014. If you have any questions regarding this event or would like RIPE NCC staff to contribute to your IPv6 events please contact us via ipv6actnow [at] ripe [dot] net On behalf of the RIPE NCC External Relations Team, Marco Hogewoning

2 1

Re: [ipv6-wg] ipv6-wg Digest, Vol 26, Issue 13
by behroz abbaszadeh 05 Nov '13

05 Nov '13

I read the presentation; It has some benefits and some problems. This kind of IPv6 addressing maybe decrease network security and it will give opportunity to hackers to access to the special networks by special IPv6 address scanning. Thank you Behrouz ________________________________ From: "ipv6-wg-request(a)ripe.net" <ipv6-wg-request(a)ripe.net> To: ipv6-wg(a)ripe.net Sent: Sunday, October 27, 2013 2:30 PM Subject: ipv6-wg Digest, Vol 26, Issue 13 Send ipv6-wg mailing list submissions to ipv6-wg(a)ripe.net To subscribe or unsubscribe via the World Wide Web, visit https://www.ripe.net/mailman/listinfo/ipv6-wg or, via email, send a message with subject or body 'help' to ipv6-wg-request(a)ripe.net You can reach the person managing the list at ipv6-wg-owner(a)ripe.net When replying, please edit your Subject line so it is more specific than "Re: Contents of ipv6-wg digest..." Today's Topics: 1. Re: 96 more bits... time for some magic after all? (Yannis Nikolopoulos) 2. Re: 96 more bits... time for some magic after all? (Benedikt Stockebrand) 3. Re: 96 more bits... time for some magic after all? (Yannis Nikolopoulos) ---------------------------------------------------------------------- Message: 1 Date: Sat, 26 Oct 2013 15:52:34 +0300 From: Yannis Nikolopoulos <dez(a)otenet.gr> Subject: Re: [ipv6-wg] 96 more bits... time for some magic after all? To: ipv6-wg(a)ripe.net Message-ID: <526BBB12.1090705(a)otenet.gr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hello, On 10/25/2013 06:53 PM, S.P.Zeidler wrote: > Thus wrote Shane Kerr (shane(a)time-travellers.org): > >> We saw two presentations by network architects at the RIPE meeting that >> used bits in their IPv6 addressing plan to carry meaning beyond simple >> network topology and packet routing. >> >> For example, declaring a specific bit in the address to be 1 for voice >> traffic or 0 otherwise. > [...] > >> What should we do about it? > As a RIR, nothing. what about as one of RIPE's WGs? Should we go on and produce a BCP document of some kind? As the author of this addressing plan (https://ripe67.ripe.net/presentations/222-ripe67-yanodd-ipv6-addressing.pdf) , my main motivation for presenting it was to show that it is possible to encode basic information in an addressing plan (without wasting too much space) and still keep it simple . For example, even IPv4 addressing plans were location-aware, that's nothing new. Well, its even easier and more effective in IPv6 addressing, because of the number of bits available. As far as encoding service type, no space is wasted because it is encoded after the /56 boundary ;) , even making it possible for QOS. As I mentioned in the presentation, this is our 3rd or 4th try over the past ~10 years. So far, with the help of some basic heuristics, it seems to be working out fine cheers, Yannis > > Otherwise: violations of the KISS principle are rarely a good idea. > In this case, you might find out that you snuck yourself into a > straightjacket a few years down the line. > > regards, > spz ------------------------------ Message: 2 Date: Sun, 27 Oct 2013 07:54:42 +0000 From: Benedikt Stockebrand <bs(a)stepladder-it.com> Subject: Re: [ipv6-wg] 96 more bits... time for some magic after all? To: Roger J?rgensen <rogerj(a)gmail.com> Cc: "ipv6-wg(a)ripe.net IPv6" <ipv6-wg(a)ripe.net> Message-ID: <87ob6bkv25.fsf(a)stepladder-it.com> Content-Type: text/plain; charset=utf-8 Hi Roger and list, On Fri, Roger J?rgensen <rogerj(a)gmail.com> writes: > Oct 25, 2013 at 5:24 PM, Benedikt Stockebrand > <bs(a)stepladder-it.com> wrote: >> [...] >> More important however is the question how to deal with them if /when >> they show up because they have unnecessarily "depleted" their address >> assignment thanks to encoding stuff in it. >> [...] > If they run out due to size and growth, and they haven't wasted space, > used their available /29 wisely by every advice given...give them > another prefix. That's what I meant by "unnecessarily 'depleted'". If they actually grow beyond their /29 or whatever, let them have another prefix. What I wouldn't want to see however is that some big player gets some extra address space because they wasted their existing one. Once that happens, everyone will demand the same. And yes, I've had these discussions. In particular, the idea to bit-encode the services (i.e. significant port numbers) somewhere in the subnet prefix. Eventually these people decided "well, we have a /12 for IPv4, so it's only fair we also get a /12 for IPv6". At that point I pretty much gave up and told them to request that from their RIR... > One way to waste is to give every single customer a /48 when you are > really really big. /56 work just fine really, even for techies like me :) Sorry, but I disagree on that. A /56 is fine for today's requirements, but if this hype about the "Internet of Things" really takes off and you want to put things into different subnets, a /56 may occasionally be a problem even for consumer households. Not today, but think anything from ten to fourty years. > However IPv6 is big enough that most people will not feel any pain with > it, some however will start to get into trouble in 5-10years time, guess > more like around in 7 years. The reason? They made a too static model > on how they wanted to use their available space. Agreed, but... > But you have to be big to get into that trouble. I don't see any reason why size has to do with it. The problem is more of a ratio between size and allocated address space---and the technical knowledge around. (And no, unlike somebody else on this list I don't believe it feasible for a consumer to call in a CCIE every time they need some networked deviced hooked up.) > There was major discussion just to get that /56 into the documents. > Upto that point there was /64 pr.LAN, /48 for the rest. Now we're relaxing > it even more. Are discussion on moving away from /64's on the wire to... If /64 is given up, all sorts of shit will happen. It has been part of the specs for long enough that a number of implementations will rely on it. It's not just autoconfiguration, but when it comes to embedded system/microcontroller implementations, changing that is rather difficult. Additionally, anything that can be (mis-)configured exponentially adds (or rather, multiplies) to the frustration potential for end users. > Doesn't this sound like A/B/C-class network vs CIDR? You mean VLSM, I assume? > * For one server running in the cloud I got a /112, that work just fine really. ...until you do an upgrade on the server that relies on RFC 4291. > * Somewhere else I'm using a /50 on the wire, that also work just fine. Same issue. Yes, at least some implementations support that right now, but you shouldn't rely on that. Additionally, for whoever may have to run that system further later on you set up some ugly surprise that way. > * I have tried to use an entire /48 but failed. I tried to build my > own network with VPN, routings and everything across the different > servers and routers I have spread around. That /48 was big enough for > me:) Oha. So you have too many machines to fit into a /64 in a single subnet? > * I tried to build a big routed, multisite network using a /56, that > also worked upto a certain size :) Sorry, I don't get what you want to say there. Cheers, Benedikt -- Business Grade IPv6 Consulting, Training, Projects Benedikt Stockebrand, Dipl.-Inform. http://www.stepladder-it.com/ ------------------------------ Message: 3 Date: Sun, 27 Oct 2013 12:02:46 +0200 From: Yannis Nikolopoulos <dez(a)otenet.gr> Subject: Re: [ipv6-wg] 96 more bits... time for some magic after all? To: Benedikt Stockebrand <bs(a)stepladder-it.com> Cc: "ipv6-wg(a)ripe.net IPv6" <ipv6-wg(a)ripe.net> Message-ID: <526CE4C6.9060003(a)otenet.gr> Content-Type: text/plain; charset=UTF-8; format=flowed On 10/27/2013 09:54 AM, Benedikt Stockebrand wrote: > Hi Roger and list, > > On Fri, Roger J?rgensen <rogerj(a)gmail.com> writes: > >> Oct 25, 2013 at 5:24 PM, Benedikt Stockebrand >> <bs(a)stepladder-it.com> wrote: >> What I wouldn't want to see however is that some big player gets some >> extra address space because they wasted their existing one. Once that >> happens, everyone will demand the same. that's the second time I read this in this thread. Why would this happen? All allocations are subject to RIR policy >> One way to waste is to give every single customer a /48 when you are >> really really big. /56 work just fine really, even for techies like me :) > Sorry, but I disagree on that. A /56 is fine for today's requirements, > but if this hype about the "Internet of Things" really takes off and you > want to put things into different subnets, a /56 may occasionally be a > problem even for consumer households. Not today, but think anything > from ten to fourty years. 40 years from now? Many, more significant changes will probably overshadow this. Otherwise, 256 different policies in a home sound just fine > >> There was major discussion just to get that /56 into the documents. >> Upto that point there was /64 pr.LAN, /48 for the rest. Now we're relaxing >> it even more. Are discussion on moving away from /64's on the wire to... > It's not just autoconfiguration, but when it comes to embedded > system/microcontroller implementations, changing that is rather > difficult. care to elaborate on that? >> * For one server running in the cloud I got a /112, that work just fine really. > ...until you do an upgrade on the server that relies on RFC 4291. > >> * Somewhere else I'm using a /50 on the wire, that also work just fine. > Same issue. Yes, at least some implementations support that right now, > but you shouldn't rely on that. Additionally, for whoever may have to > run that system further later on you set up some ugly surprise that way. again, care to elaborate a bit? How's a /50 not compliant with RFC 4291? > Cheers, Benedikt cheers, Yannis End of ipv6-wg Digest, Vol 26, Issue 13 ***************************************

1 0

96 more bits... time for some magic after all?
by Shane Kerr 31 Oct '13

31 Oct '13

All, [ gah... hit the wrong key and sent this unfinished ] We saw two presentations by network architects at the RIPE meeting that used bits in their IPv6 addressing plan to carry meaning beyond simple network topology and packet routing. For example, declaring a specific bit in the address to be 1 for voice traffic or 0 otherwise. There are motivations for doing this, which may or may not be valid in any particular case. There are ways to lessen the amount of addresses consumed by this (for example by assigning /56 instead of /48 to end users). But I think that the important thing is that we have historically not considered this sort of use with address allocation policy. In face, RFC 2050bis was *just* published as RFC 7020: http://datatracker.ietf.org/doc/rfc7020/ This includes the long-standing historical goals of conservation, aggregation, and accuracy. Using bits in IPv6 networks for other purposes is orthogonal to those goals. What should we do about it? Cheers, -- Shane

11 22

[training] RIPE NCC Webinars - new dates
by Training Team 29 Oct '13

29 Oct '13

Dear colleagues, We are pleased to announce the launch of new dates for our Webinars. The RIPE NCC Webinars are live and take only one hour. You can interact with our trainers without leaving your desk. 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 <training(a)ripe.net>. We look forward to seeing you online. Kind regards, RIPE NCC Training Services

1 0

96 more bits... time for some magic after all?
by Shane Kerr 26 Oct '13

26 Oct '13

All, We saw two presentations by network architects at the RIPE meeting that used bits in their IPv6 addressing plan to carry meaning beyond simple network topology and packet routing. For example, declaring a specific bit in the address to be 1 for voice traffic or 0 otherwise. There are motivations for doing this, which may or may not be valid in any particular case. There are ways to lessen the amount of addresses consumed by this (for example by assigning /56 instead of /48 to end users). But I think that the important thing is that we have historically not considered this sort of use with address allocation policy. In face, RFC 2050bis was *just* published as RFC 7050: Cheers, -- Shane

2 1

Request for feedback on IETF I-D draft-v6ops-vyncke-balanced-ipv6-security
by Anfinsen, Ragnar 22 Oct '13

22 Oct '13

Dear all, The authors would like to invite the community to review and comment on IETF I-D draft-v6ops-vyncke-balanced-ipv6-security. <snip> Abstract This document describes how an IPv6 residential Customer Premise Equipment (CPE) can have a balanced security policy that allows for a mostly end-to-end connectivity while keeping the major threats outside of the home. It is based on an actual IPv6 deployment by Swisscom and proposes to allow all packets inbound/outbound EXCEPT for some layer-4 ports where attacks and vulnerabilities (such as weak passwords) are well-known. </snip> http://tools.ietf.org/html/draft-v6ops-vyncke-balanced-ipv6-security We have received feedback from the IETF community that there should not be any explicit list of ports to be blocked in the document. The authors feels that this list should be maintained by a neutral internet body, however we need suggestions from the community on who this could be solved. So basically there are a few options on who the list could be managed; * Let the ISP/Vendor define and maintain the list by them selves. * Let the community maintain such list using consensus. * Ask a neutral internet body (insert favorite here) to manage the list based on the actual threat picture. Please keep in mind that this draft is not meant to define an IDS/IPS style of functionality. We are only looking for how to solve the IPv6 firewall default on/off problem. This draft only covers the default list provided when the customer is begin connected. The customer can, depending on the ISP's policy, fully administer the firewall rules. Best Regards The authors; Eric Vyncke, Cisco Martin Gysi, Swisscom Guillaume Leclanche, Swisscom Ragnar Anfinsen, Altibox

2 1

IPv6 Only Network at RIPE 67
by Marco Hogewoning 21 Oct '13

21 Oct '13

"It's an IPv6 Working Group Initiative!" Dear Colleagues, Following the discussion at RIPE 66, the IPv6 Working Group is happy to provide you with an experimental network that is configured to offer only IPv6. This experimental network is not supported by the RIPE NCC or RIPE 67 Technical Team. We encourage everybody to connect to this network and test any websites, applications, hardware and software, and verify that they operate when an IPv4 address is no longer available. Important: This network is an experiment and is offered on a best-effort basis. We will try to maintain sufficient service levels and are happy to look into and help troubleshoot any issues you may encounter. If you rely on network connectivity for important business, we recommend you connect to the regular RIPE Meeting network. How to connect: - Make sure IPv6 is enabled on your device - Connect to SSID: IPV6ONLYEXP - Enter the password: iknowbesteffort The network provides NAT64 translation to connect to legacy services – please use the name server provided by the network to make use of this feature. We suggest you leave IPv4 enabled as this will be the scenario for most end users. Feedback: Please see Marco Hogewoning or Andrew Yourtchenko for any issues. We invite you to attend the IPv6 Working Group session on Thursday from 9:00-10:30 to discuss the results of this experiment. And of course you are welcome to follow up on this mailing list. Greetings, Marco Hogewoning Andrew Yourtchenko

12 34