- ipv6-wg - mailman.ripe.net

IPv6 troubleshooting for helpdesks - draft v.01
by Jan Zorz ＠ go6.si 09 Sep '14

09 Sep '14

Dear IPv6 WG, Just to let you know, the co-authors of "IPv6 troubleshooting for helpdesks" document published the next version of the document with some new and also a bit more fine tuned old content and revised structure. Please find the latest version in attach and also at following URLs: http://go6.si/ipv6-troubleshooting-for-helpdesks/ http://go6.si/docs/IPv6-troubleshooting-for-helpdesks-v01.pdf (direct download) I would like to ask IPv6 WG community to read the document and check the technical and procedural validity of the content. All ideas, comments and suggestions also welcome on this list. This document is now in the works for quite long time, so I hope that we might be approaching the final version soon ;) Cheers and thnx, Jan Zorz

1 0

IP Address Space Course this November in London
by Training Services 26 Aug '14

26 Aug '14

Dear Colleagues, We are happy to announce a new RIPE NCC training course that will take place on the Sunday before the RIPE 69 Meeting in London this November. This new course will focus on how to obtain, transfer, manage and protect your IP address space. The course is free of charge and is open to anyone interested. The course will cover the most frequently asked questions the RIPE NCC receives about IP address space. Course title: RIPE NCC Presents: IP Address Space Basics How to obtain, transfer, manage and protect your IP addresses Goals: By the end of this course, you will be able to: - Manage your IPv4 and IPv6 addresses according to current RIPE Policies - Understand how to obtain IPv4 addresses through transfers - Protect your address space from hijacking Target audience: Anyone interested in the policies and procedures around address space in the RIPE NCC service region, and companies looking at address space transfers, mergers and acquisitions. No prior knowledge of the topic is necessary. Time: Sunday, 2 November, 10:00–16:00 Outline: - Becoming a RIPE NCC member (why and how) - Obtaining IP addresses (IPv4 and IPv6) - IP address space transfers, mergers and acquisitions - IPv6 basics - Address space hijacking - Resource Certification (RPKI) Cost: Free of charge. Coffee and lunch will be provided. The course will be delivered by representatives from the RIPE NCC’s Training Services and Registration Services departments. If you are interested in attending this course, please let us know asap by sending an email to training(a)ripe.net. Be quick - we only have 40 seats available on a first come, first served basis! If there is enough interest, we will continue to offer courses on different topics of interest alongside future RIPE Meetings. Kind regards, Training Services

1 0

RIPE 69 Agenda items?
by Marco Hogewoning 20 Aug '14

20 Aug '14

Dear Colleagues, The next RIPE Meeting will be held in London from 3-7 November. As always this working group has been given a slot to meet, which is on Thursday the 6th of November at 09:00 local time. For now we only have 90 minutes, but if we have enough content that we feel is worth discussing, we can put in a request for additional time. We expect some of the time to be taken by a discussion on replacing Shane and me as chairs of this working group, but there should be more than enough left to focus on the tasks at hand. If you have a topic that is related to the deployment of IPv6, that you think is worth showing, discussing by this working group or you have any proposal for specific work items for this group, please make yourself known either via this list or an email to ipv6-wg-chairs at ripe dot net. And keep in mind our charter is not limited to IPv6 address management, we equally welcome any other topics that relate to the adoption and implementation of IPv6 that would be of benefit to the RIPE community or the global Internet community. More information about RIPE 69 and registration is available via http://ripe69.ripe.net Cheers and see you in London, Marco and Shane IPv6 WG chairs

1 0

Re: [ipv6-wg] IPv6 Addressing Plan (Daniel Baeza (Red y Sistemas TVT))
by Sonderegger Olaf ABRAXAS INFORMATIK AG 20 Aug '14

20 Aug '14

Hi Daniel >From my point of view, an IP Addressing Plan has to be done by its user. It doesn't exist an one-fits-all solution, there will be always something which is unique within your environment/your country/your service. I think, a good starting point is following SURFnet paper about "Preparing an IPv6 Adressing Plan": https://labs.ripe.net/Members/steffann/preparing-an-ipv6-addressing-plan Best regards, Olaf

3 2

[training] RIPE NCC Training Courses October-December 2014
by Training Services 19 Aug '14

19 Aug '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 Ljubljana, Norway, Tbilisi, Berlin, Bratislava, Amman, Lyon, Athens, London, Amsterdam. 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 - Basic IPv6 Training Course - Advanced IPv6 Training Course - Routing Security Training Course - DNSSEC 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

IPv6 Addressing Plan
by Daniel Baeza (Red y Sistemas TVT) 29 Jul '14

29 Jul '14

Hi all, Im new to this list and dont know if im doing right asking that here but, Can anyone help us a little bit on making an addressing plan? We are a Local ISP provider and we work with Coaxial(HFC), FTTH and WiFi. We have allocated a /29 but It have been split into 8 /32. We are planning to use 1 /32 for our own infraestructure and for client lease (dhcpv6) in both ways, Direct Access and PD. Thanks in advance! Best Regards, -- Daniel Baeza Centro de Observación de Red Dpto. Red y Sistemas Television Costa Blanca S.L. Telf. 966.190.847 | Fax. 965.074.390 http://www.tvt.es | http://www.tvt-datos.es Correo: d.baeza(a)tvt-datos.es -- [Atención] La información contenida en este e-mail es confidencial, privilegiada y está dirigida exclusivamente a su destinatario. Cualquier revisión, difusión, distribución o copiado de este mensaje sin autorización del propietario está prohibido. Si ha recibido este e-mail por error por favor bórrelo y envíe un mensaje al remitente. [Disclaimer] The information contained in this e-mail is privileged and confidential and is intended only for its addressee. Any review, dissemination, distribution or copying of this e-mail is prohibited. If you have received it in error please delete the original message and e-mail us. (!) El medio ambiente es responsabilidad de todos. Imprime este mail si es absolutamente necesario.

2 2

RIPE 68 Minutes
by Marco Hogewoning 14 Jul '14

14 Jul '14

Dear colleagues, Please find attached a copy of the minutes of our last meeting. Once again we like to thank the RIPE NCC for providing these and invite the community to review and report back any errors or omissions. Please send any feedback before September 1st, 2014 (allowing for holidays) after which we will publish the final version. Cheers, Marco RIPE 68 WG Chairs: Shane Kerr, Marco Hogewoning Session I: 15 May 2014, 9:00- 10:30 Scribe: Mirjam Kuehne A. Welcome and Housekeeping Shane Kerr, IPv6 Working Group Chair, opened the first session. He briefly described the IPv6-only wireless network and encouraged everyone to use it. B. IPv6 Campus Deployment Experience - Niall O’Reilly[FM1] , University College Dublin The presentation is available at: https://ripe68.ripe.net/presentations/261-RIPE68_Deploying_IPv6.pdf Jen Linkova, Google, asked how many users or devices Niall expects for the wireless network. Niall said that he expects a couple of tens of thousands. Jen added that this large number of devices on the network may have an effect on the battery life of the devices. Niall thanked Jen for the warning and said that this would be an interesting user experiment. However, he agreed that, when adding a large number of customers, the noise level on the network goes up, which may be mitigated by the access control they're using. Wilfried Wöber, Univie/ACOnet/VIX, said that they had been “playing with” IPv6 for a while at the NREN in Austria and that he was surprised to see in the most recent Akamai report that 43% of traffic with Akamai from Vienna University was IPv6 traffic, much higher than he had expected. Niall responded that this very much depends on the applications used. Benedikt Stockebrandt, Stepladder IT, referred to a document from a university in South Africa. They turned on IPv6 on the campus and observed that 56% of the traffic was IPv6 and most of it was YouTube traffic. He expected that something like this will also happen at the Dublin campus and wondered what the traceability requirements are. Niall answered that part of the agreement with Eduroam requires keeping radius and DHCP logs for six months. Jen Linkova said that, before using tools to conform that a user is using a certain IP address which was assigned by DHCP (and not statically configured), one needs to consider that DHCP doesn't necessarily give you the malicious user that was using that address. Niall responded that he is sure that they don't have complete proof against malicious attacks but that the majority of users want to use the network and the set-up, and the existing tools seem to be adequate for this purpose (logs from wireless controllers and access lists). C. IPv6 Penetration in Hungary - Janos Zsako The presentation is available at: https://ripe68.ripe.net/presentations/330-IPv6_measurements_in_Hungary.pdf Shane Kerr, Dyn, said that he was surprised to see that mail has such low penetration because it seems an easy thing to turn on. He asked Janos if he had any ideas why this is the case. Janos responded that he doesn't know and that he didn't have the opportunity to talk to the providers to find out why this is the case. He added that it might be caused by the fact that it is not yet widely spread so the servers in the backbone or in the core could have IPv6 but that it doesn't help much yet. Ondrej Calatka, CESNET, reported that he is operating automated responder tests, where you can send mail and take a reply over IPv6 and see if you are able to send to, and receive from, an IPv6-only mail server. He said that he observed some interesting things: 30% of MX records with IPv6 address don’t respond to SMTP to connect to the port. Furthermore, when you are lucky enough to connect to the SMTP service, some IPv6-only host names respond with an invalid host name. There is also other anti-spam, anti-malware and other measures that are IPv4 only. So, even if you are communicating over IPv6 with the SMTP server, it means that you can only deliver mail with IPv6, therefore it's somewhat “horrible”. Janos agreed and said that he also looked at common errors in MX records. Often, he saw local hosts or there are IP addresses inside or many other bugs. Alex, participating via chat, asked whether the percentages shown are of MX, NS, WEB servers, or percentages of .hu domains with working service. Alex also asked, “Who are the champions of turning IPv6 on in .hu?” Janos clarified that the percentage of servers that we see is much lower than the percentage of domains serving those servers. In response to Alex’s second question, he stated that the academic network was one of the pioneers many years ago but he wanted to concentrate on the current situation. Sebastian Castro, .nz Registry Services, reported that he sees similar numbers: higher level of adoption on name servers compared to adoption on mail and web servers. He added that they are scanning all domain names for A and AAAA records, that they are happy to share the data and that the IPv6 task force in New Zealand also has interesting numbers. Jan Zorz said that he also sees the same issues with mail servers and suggested that people use protocols that work over IPv6 (such as DKIM). He referred to a recent article published by Frank Martin on RIPE Labs: https://labs.ripe.net/Members/mirjam/sending-and-receiving-emails-over-ipv6 George Michaelson, APNIC, said that the different numbers Janos presented are because different people are measuring different things (mostly quantitative measurements). George commented that Janos is performing more qualitative measurements to assess capacity and capability, and it is common knowledge that that the centre is better than the edge. Therefore, it may not be surprising to see that the edge measurements Janos is performing are lower. Finally, he added that he was struggling to send traceroutes into IPv6 space in Hungary- the richness of the peering narrows pretty quickly. Andrea Cima, RIPE NCC, referred to the quality of registration data in IPv6 as opposed to IPv4 data, as Janos mentioned in his presentation. The RIPE NCC has also been thinking about this: for IPv4 there was a much closer feedback loop between the RIPE NCC and the LIRs, especially when LIRs come back for more resources. For IPv6, that is not the case. Most LIRs will never come back for an additional allocation. Also, before 2011, LIRs were not required to register End User assignments in the RIPE Database. Recently, it was decided to create a new auditing process that is much more lightweight and focused on advice and support (the Assisted Registry Check, which has been very successful so far). The plan is to contact 3,000 LIRs every year and the RIPE NCC wants to make it easy for LIRs to maintain their resources. An unnamed speaker from Romania said that they are running the biggest IPv6 network in the country. However, he added that they could not expand into Hungary, because the Hungarian regulator did not authorise lawful interception. D. Painting by Numbers (Visualisation of Structured IPv6-Addressing) - Helge Holz, Dataport The presentation is available at: https://ripe68.ripe.net/presentations/344-Painting_by_Numbers.pdf Jen Linkova congratulated Helge on this work and asked if it can also be used for other environments. She suggested making it public so that others can also use it. Helge said that, currently, it is not very stable but added that he certainly wants to make it public, which why he is presenting it at the RIPE Meeting. Geoff Huston, APNIC, asked what would happen if the libraries would want to connect separately from all the schools. Helge clarified that In Germany that won't be the case. Niall stated that this algorithm has properties that he needs for his operations and that he couldn't work it out by himself. Therefore, he is very happy about Helge's algorithm and thanked him for it. E. What the Future Holds Ondrej Sury, CZ.NIC Ondrej showed some slides from his presentation that was presented in full at the Open Source Working Group about Knot DNS. The full presentation is available at: https://ripe68.ripe.net/presentations/262-KNOT-20140514-RIPE68.pdf Wilfried Woeber asked for confirmation: if one has a particular entry for the 4-bit zone, you cannot automatically give the answer if queried for the reverse. Ondrej answered that it is the case and that it doesn't match the zones together. It just creates a pattern that will generate “on the fly” if somebody asks for the name. Session II: 15 May 2014, 11:00- 12:30 Scribe: Emile Aben At the beginning of the session, Working Group Chair Marco Hogewoning mentioned the availability of an IPv6-only WiFi network. F. RIPE IPv6 Analyser Alex Band, RIPE NCC The presentation is available at https://ripe68.ripe.net/presentations/338-IPv6_Analyser.pdf There were no questions for this presentation. G. BCOP Document: “IPv6 troubleshooting procedures for helpdesks” - Jan Zorz, ISOC The presentation is available online: https://ripe68.ripe.net/presentations/343-Jan_Zorz_IPv6_helpdesk.pdf Ragnar Anfinsen, Altibox, said that he had received positive feedback on this from his helpdesk. He asked for additional text for expert users on the website, so that they can fix problems themselves. Jan clarified that this is the plan. Jen Linkova said that it's a great idea, and added that she had already given detailed comments by email. She wondered about the procedure and indicated that there are too many places to track and comment on this work and that it needs one place where discussion can take place. After a discussion, it was agreed that technical comments should go to the IPv6 Working Group mailing list. H. IETF document: “Balanced Security for IPv6 Residential CPE” - Ragnar Anfinsen, Altibox The presentation is available online at: https://ripe68.ripe.net/presentations/358-Balanced_Security_-_IPv6_Security… Sander Steffann, SJM Steffann, said that this effort is heading in the right direction that it's very important to both show advice and experiences from people who have already done this. Jan Zorz said that his suggestion at the IETF was to verify the document with the operational community, and mentioned BCOP as a means to do this. Jan asked if the CPE (Customer Premises Equipment) vendors showed interest in this. Ragnar said that they didn't show interest. This is mainly for service providers that manage the CPE and it is quite complex for retail CPE. Jan suggested taking this to the openCPE project, or to Terrastream's version of that. Benedikt Stockebrandt indicated that there are cultural differences on what approaches to adopt and it would be good to account for these. Mathew Moyle-Croft, Amazon, suggested offering customers the ability to do upstream filtering, as an alternative to filtering on the CPE, as it's easier to manage and reduces traffic. Ragnar said that the draft is about filtering as a service, and is therefore not necessarily specific to CPE. I. RIPE_554bis - Sander Steffann, RIPE NCC The presentation is available at: https://ripe68.ripe.net/presentations/340-RIPE-554bis.pdf Shane Kerr stated that this document is one of the success stories of this working group, but things need to be updated continuously. Benedikt Stockebrandt said that the size of the document scares people off. He suggested to split it up in different documents addressing different areas, and indicated choosing connectivity as one of these. Wilhelm Boeddinghaus, BCIX/Iubari, warned against setting the scope too wide and suggested keeping the focus with hardware, and not to engage in cloud or software-defined networking (SDN) because this will result in discussions. These, and connectivity need new documents. Marco Hogewoning agreed with previous comments, and indicated that the document is widely used. He suggested adding text to the document on how updates to the document are handled. He argued to not obsolete ripe-554, “Requirements for IPv6 in ICT Equipment”, but make a new document that is referenced everywhere, to help people who are not familiar with the processes. He proposed keeping both ripe-554 and the new document alive. Sander agreed, and considered different wording might help, and to not call it obsoleted. Shane said that it wasn't clear to him how that would work. Sander pointed out that ripe-501, “Requirements for IPv6 in ICT Equipment”, is called obsoleted and much downloaded, and called for careful communication regarding this. Jan Zorz called for language polishing by native speakers. He added that, for the connectivity part, he is maintaining that list, and, due to an error, it wasn't in ripe-554. He volunteered to work on the connectivity part. Sander said that he wants to do ripe-554 first, and later take the extra parts to the mailing list. Mirjam Kuehne, RIPE NCC, indicated that the RIPE NCC is always happy to do language review of these documents. J. IPv6 deployment at CERN - Edoardo Martelli, CERN The presentation is available at: https://ripe68.ripe.net/presentations/294-cern-ipv6-deployment.pdf Jen Linkova asked about the plans for IPv6 on external services, because they are not dual-stacked. Edoardo said that, internally, services are IPv6-ready, but are not externally ready for various reasons- for mail, due to lack of IPv6 support in their anti-spam software and for web server because they didn't dare to. Shane Kerr wondered if they saw more questions coming into their customer support, because that was a concern for IPv6 World Day. Edoardo said that most questions were about how to use it, not about problems. Shane mentioned that there are people working to eliminate the need for Router Advertisement (RA), so to be able to use only DHCPv6. Lionel Hoffmann, Bouygues Telecom, asked if the tools mentioned in the presentation were all homemade. Eduardo confirmed that most of it is homemade. Lionel also asked about experiences with specific applications having problems with IPv6, and CERN's plans for applications that only support IPv4. Eduardo explained that they test whether applications keep working on dual-stacked machines, even if the application doesn't use IPv6. For some legacy applications, like AFS, he expected never to get IPv6 support, so they cannot phase out IPv4 at the moment. Lionel asked if dual-stack is a step towards IPv6-only. Eduardo answered that, currently, they expect to be dual-stacked forever. K. Selection of a New Working Group Chair Marco and Shane discussed David Kessens stepping down as one of the chairs of the IPv6 Working Group and how to fill the vacancy. Marco and Shane also intend to be gradually replaced. Working group chairs are replaced by consensus of the working group. They said that they would take the process to the mailing list. They then invited people to comment on this and to step forward as potential IPv6 Working Group Chairs. Jan Zorz thanked David Kessens for his service and was willing to step forward as a candidate, but would need to work out how to combine that with chairing the BCOP Task Force. Jen, Dave Wilson, HEAnet, and Dmitry Kohmanyuk, Hostmaster, also stepped forward as candidates. Rob Evans, JANET, indicated that this is really good in the light of periodic reaffirmation of working group chairs. He was disappointed that Marco and Shane won't stand again. The IPv6 Working Group chairs thanked participants for attending and stated that they hope that they would see the participants in London at the next RIPE Meeting. Marco Hogewoning urged participants to try the IPv6-only network and closed the session. [FM1]Org?

1 0

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

is use of IF-ID 0 "clean"
by Wilfried Woeber 27 Jun '14

27 Jun '14

Dear WG-folks, out of curiosity and because I got asked this question, here we go: Is the use of "0" as the interface ID in an IPv6 network "clean"? I haven't found any indication that "0" is reserved (as in IPv4), or should not be used, but there's a lingering feeling that it may cause trouble, somewhere, somehow. Any input appreciated, tia, Wilfried.

5 5

[training] RIPE NCC Webinars - new dates
by Training Services 24 Jun '14

24 Jun '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

New on RIPE Labs: The IPv6 Analyser
by Mirjam Kuehne 20 Jun '14

20 Jun '14

Dear colleagues, The IPv6 Analyser is a toolset that offers our members a visual insight into all the allocations, aggregations and assignments they have made. This toolset seamlessly integrates with the RIPE Database, allowing you to create new objects with an easy-to-use wizard. It was announced before the RIPE 68 meeting, and we're now seeing LIRs starting to use it. Please find some more details in this RIPE Labs article: https://labs.ripe.net/Members/AlexBand/the-ipv6-analyser Please let us know if you have any comments or questions. Kind regards, Mirjam Kuehne RIPE NCC

1 0

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

10 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

Re: [ipv6-wg] IPv6 only network (not just at RIPE xx meeting)
by Geert Jan de Groot 06 Jun '14

06 Jun '14

Hi all, Not attending RIPE-meetings myself anymore these days, I'm not sure whether (just) a IPv6-only network at a meeting is going to cut it. This has been done for a number of years worth of meetings and while the results are interesting, I'm not sure that a RIPE-meeting is a requirement to run these experiments. It makes perfect sense to run a V6-only network at home/office and get the experience all year, not just during a meeting. So, as a typical home user these days, I run a V6-network, some pieces of it being V6-only, other places being V6-preferred, and the experiences are, eumm, mixed. I frequently find sites (at various ISP's) that are either partially or fully broken for V6. In many instances, happy eyeballs rescues things, that is, things seem just slow but not entirely broken unless one analyzes. Reporting a V6-broken website to it's hoster is, in many cases, a waiste of time. Helpdesks don't understand the problem. If I'm lucky I get a response. Problems are seldom resolved. I think I see this five times per month or so. Perhaps I should browse less. Thing is, we seem to be working on making the Internet V6-capable, but currently V6 performance and stability is a serious issue, especially when it comes to reporting problems. Happy eyeballs mean that the V6-network can, in many cases, just be switched off without anybody noticing. We all know of stories of support/helpdesk folk telling people just to switch off V6. That's all nice if it'd just be an academic exercise but not if it is supposed to be the main bread and butter in the years to come. So, my question to the WG: does the WG think this is a problem, and can we think of a way to get clueful v6 complaints to clueful handlers, instead of being ignored / misaddressed / ...? Geert Jan

4 4

Swiss IPv6 Business Conference in Zurich, June 17 - register now!
by Silvia Hagen 04 Jun '14

04 Jun '14

There is an IPv6 conference coming up on June 17, at Arena Sihlcity in Zurich. We have a great lineup of international speakers, over 15 sessions in two tracks (business and technical), great networking opportunities. Find all information and registration at www.ipv6conference.ch<http://www.ipv6conference.ch> This is the third edition of the annual IPv6 conference organized by the Swiss IPv6 Council (www.swissipv6council.ch<http://www.swissipv6council.ch>). See you soon Silvia Hagen Chair Swiss IPv6 Council Swiss IPv6 Council CH-8124 Maur +41 (0)44 887 62 10 www.swissipv6council.ch http://twitter.com/IPv6CouncilCH *********************************** Switzerland is Number 2 in IPv6 User Adoption Gearing up to 20% in 2014! *********************************** Our website is dual-stack - how about yours? ***********************************

1 0

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