May 2014 - ipv6-wg - mailman.ripe.net

IPv6 only network at RIPE 68
by MarcoH 12 Jul '14

12 Jul '14

Hello, First of all let me use this opportunity to say thank you to Andrew Yourtchenko and the RIPE NCC staff for all their support and work in making this available. Statistics show that again quite a lot of people have used or at least tried this network. A few issues bubbled up, but they were all related to issues with 3rd party software and one minor incident with the layer 2 infrastructure that was not related to our specific setup. Please feel free to give feedback about this experiment on this list. But also please consider relaying it back to the developers or companies and compliment with a nice job done or ask them to fix any bugs you may have encountered. Thanks, MarcoH -- Sent from mobile, sorry for the typos

23 65

Re: [ipv6-wg] [bcop] BCOP presentation at RIPE meeting in Warsaw
by Jan Zorz ＠ go6.si 11 Jun '14

11 Jun '14

[now with IPv6 WG address in cc:, actually] On 15/05/14 00:57, Jen Linkova wrote: > Hi Jan, > > finally I've managed to summarize my comments to the doc ;) Hi, thank you very much for all your comments. I'm bringing part of this discussion to IPv6 WG mailing list as it is of technical nature and I think it belongs here. I put all your comments in our issues tracker, reachable publicly at https://git.steffann.nl/go6/ipv6-troubleshooting-for-helpdesks/issues > 1) You suggest to have a local mirror of the test-ipv6. While it > definitely makes sense, using the local mirror might hide some edge > connectivity issues so it worth mentioning. We might recommend to use > *both*. Yes, absolutely. This diversity would also help the ISP to understand if he has any IPv6 issues in other parts of the network other than access ;) > > 2) Section 5 > You provide detailed instruction on how to run ping, but then saying > just 'check DNS settings' and even 'configure different servers' - > support engineers who need explanations on ping, would need more > detailed explanations on how to change DNS settings. > > "If IPv4 is working but the page is unavaliable' - I'd assume that an > engineer could not tell if 'IPv4 is working'. So IMHO we shall just > say that if site is unreachange - troubleshoot as any other 'I can not > open this page' v4-only case. > If we believe that troubleshooting such case is in scope of this > document, I'd suggest to include traceroute as a troubleshooting step. seems as a good idea. let us think about that ;) > > 3) Helpdesk code section: > I'd use different fonts/color to distinguish between 'fixed' and > 'example' fields in the output. > > 4) Code 112 (v4 + broken Ipv6) > > - can we show the process as a flowchart? if-then-else? that's a bit hard one... do we have anybody specialized in flowcharts here? > For example, the doc says 'determine if Ipv6 is offered'. I'd add 'if > it is not,, the customer either has a misconfigured CPE (which has > IPv6 enables while it should not), or there is other Ipv6-enabled > device which is used as a router. Check CPE configuration/state for > IPv6 and disable it if it has it enabled'. > > - I'd re-phrase step 2 as smth like 'if IPv6 is offered to the > customer and you manage their CPE, check if CPE has a approved > firmware version. Upgrade it if it does not'. > > - I'd say that grep (to find the IPv6 address on MacOS) should be > 'grep -E "en|inet6" so interface name is visible (to avoid the scnario > when addresses are assigned to wrong interface); > > - the IPv6 addresses table is a little bit confusing: > -- it contains 6to4 case which should not cause code 112 (as well as > Teredo case); > -- some sections say 'call theor router vendor for support'. I > believe we shall clarify somewhere in the beginning of the document > that we assume that the support deals with customers CPE and if it is > not a case, those CPE-related instructions should be either 'escalate' > or 'advise customer to contact their router vendor for support' (which > in my reality would never happen.....:) > -- as each section of the tabel has instructions (and the last row > says 'escalate', it is not clear in which case the engieer should > proceed to the next step (checking the home router config). > > the section of home router config check is a little bit confusing. > When we just say 'check the configuration of the device', it does not > mean much as we don't specify what we are looking for. Maybe we shall > say smth like: > - 'if CPE is managed by your support, check if CPE is configured as > per your internal documentation' (as we might say somewhere in the doc > that in that case it is strongly recommended to have a separate how-to > on what should be configured on those CPEs); > - check if the LAN interface has IPv6 address from the ISP allocated range; > - check on user device if it has routers's both link-local (fe80:...) > and ISP-assigned address in the neighbor discovery cache (<provide > commands); > - check the routing table on the user's device; see if the default > route points to the router's address. If not - check if DHCP and or > RAs are enabled on the home router. > - run ipv6 traceroute to isp.test-ipv6 site and see where the traceroure stops. I think this are all good suggestions. We'll go through them during our authosr edit cycle meeting, probably during the IETF meeting in Toronto. > > > Code 46 Section > - I'd sugegst to run traceroute to see where it stops. If traceroute > does not show any issues - escalate. If it does outside of your > network - contact the affected netwokr NOC. ack... > > > IMHO a section should be added which explains what kind of information > should be collected for an escalation. I'd suggest: > - Ipv4 and Ipv6 traceroute; > - ifconfig output > - routing table output > - maybe packet capture for the session which is having issues. I think this is asking a bit too much to a first level helpdesk employee... I don't know... Cheers, Jan

3 5

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 22 May '14

22 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