- ipv6-wg - mailman.ripe.net

Promote the use of IRC
by Daniel Baeza (Red y Sistemas TVT) 13 Aug '15

13 Aug '15

Hi all, Yesterday, I've started a discussion in the member list about promoting the use of IRC instead of Mail List for some kind of discussions, chit chat, etc. Not much members answered, but all who did said yes. The goal is to have, at least, one channel per mail list, but not limited to only that. For this list, an #ipv6 channel will be created and administrated by the WG Chairs. We want to use the actual RIPE IRC Server plus Network Services and some more irc servers linked to the Ripe one. What do you think? Regards, --Daniel

10 15

New IPv6 Tutorials Available Online
by Pedro Vaz 27 Jul '15

27 Jul '15

Dear colleagues, We are pleased to announce that two new IPv6 videos are now available as part of our growing collection of E-Learning Tutorials. You can find these here: Neighbor Discovery Protocol: https://www.ripe.net/support/training/learn-online/videos/ipv6/ipv6-fundame… 464XLAT: https://www.ripe.net/support/training/learn-online/videos/ipv6/transition-m… These videos also form part of the "Introduction to IPv6" online course that is available through the RIPE NCC Academy. If you want to join this course, you can register here: academy.ripe.net. The RIPE NCC Academy and RIPE NCC E-Learning Tutorials are a free service available to everyone. We plan to announce even more exciting E-Learning news in the coming months, so stay tuned! If you have any questions or comments, feel free to contact us at<e-learning(a)ripe.net>. Happy learning! Kind regards Pedro Vaz Trainer/Graphics Animator RIPE NCC

1 0

IPv6 martian filter-set
by Yannis Nikolopoulos 09 Jul '15

09 Jul '15

Hello, I'm not sure if people are using the fltr-martian-v6 filter set maintained by Job Snijders: filter-set: fltr-martian-v6 descr: Current IPv6 martians mp-filter: { 0000::/8^+, # loopback, unspecified, v4-mapped 0200::/7^+, # Reserved by IETF [RFC4048] 2001::/32^-, # Teredo prefix [RFC4380] 2001:db8::/32^+, # NON-ROUTABLE range to be used for documentation purpose [RFC3849] 2002::/16^-, # 6to4 prefix [RFC3068] 3ffe::/16^+, # used for the 6bone but was returned [RFC5156] 5f00::/8^+, # used for the 6bone but was returned [RFC5156] fc00::/7^+, # Unique Local Unicast [RFC4193] fe80::/10^+, # Link Local Unicast [RFC4291] fec0::/10^+, # Reserved by IETF [RFC3879] ff00::/8^+ # Multicast [RFC4291] } I'm trying to figure out why prefixes like 0200::/7 or 0400::/6 are not included in this list Any ideas? cheers, Yannis

2 2

RIPE71 IPv6 WG: call for presentations
by Jen Linkova 07 Jul '15

07 Jul '15

Dear IPv6 Enthusiasts, RIPE71 is just 4 months away and it's time to start thinking about IPv6 WG session agenda! If you would like to present, or just have any suggestions on what we should discuss) - please email ipv6-wg-chairs(a)ripe.net. If you would like to present, we need the following information: - a tentative title of your talk; - short summary - how much time you need (I'd recommend allowing 5 mins for questions). Thank you! -- SY, Jen Linkova aka Furry on behalf of IPv6 WG chairs.

1 0

Fwd: Operational Implications of IPv6 Packets with Extension (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-00.txt)
by Fernando Gont 01 Jul '15

01 Jul '15

FYI To the extent that it's possible, please discuss the I-D on the IETF v6ops mailing-list. But feel free to discuss it here anyway (I'll monitor the list for comments). Thanks! Best regards, Fernando -------- Forwarded Message -------- Subject: Operational Implications of IPv6 Packets with Extension (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-00.txt) Date: Wed, 01 Jul 2015 17:35:11 -0300 From: Fernando Gont <fgont(a)si6networks.com> To: v6ops(a)ops.ietf.org <v6ops(a)ietf.org> CC: draft-gont-v6ops-ipv6-ehs-packet-drops(a)tools.ietf.org Folks, A group of us published a new I-D trying to summarize the operational and security implications. It is meant to summarize the reasons for which operators may intentionally drop IPv6 packets containing IPv6 extension headers. The I-D is available at: <https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-drops…> As far as this I-D is concerned, think of us co-authors as the messengers. The I-D doesn't argue itself whether you should (or should not) drop packets with EHs, but simply discusses the challenge they represent in some scenarios. Comments will be more than welcome. Thanks! Best regards, Fernando -------- Forwarded Message -------- Subject: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-00.txt Date: Wed, 01 Jul 2015 13:29:21 -0700 From: internet-drafts(a)ietf.org To: Gert Doering <gert(a)space.net>, Nick Hilliard <nick(a)inex.ie>, Shucheng LIU (Will) <liushucheng(a)huawei.com>, Gert Doering <gert(a)space.net>, Warren Kumari <warren(a)kumari.net>, Will Liu (Shucheng) <liushucheng(a)huawei.com>, Fernando Gont <fgont(a)si6networks.com>, Nick Hilliard <nick(a)inex.ie>, Fernando Gont <fgont(a)si6networks.com>, Warren Kumari <warren(a)kumari.net> A new version of I-D, draft-gont-v6ops-ipv6-ehs-packet-drops-00.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Name: draft-gont-v6ops-ipv6-ehs-packet-drops Revision: 00 Title: Operational Implications of IPv6 Packets with Extension Headers Document date: 2015-07-01 Group: Individual Submission Pages: 13 URL: https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-drops… Status: https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-packet-drops/ Htmlized: https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-00 Abstract: This document summarizes the security and operational implications of IPv6 extension headers, and attempts to analyze reasons why packets with IPv6 extension headers may be dropped in the public Internet. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat

1 0

Extension Headers / Impact on Security Devices
by Enno Rey 26 Jun '15

26 Jun '15

Hi, hope everybody had a great #RIPE70 meeting. We did! Many thanks to the organizers and chairs! With regard to the strong position on ext hdrs that I expressed in the session yesterday pls allow to add some material/sources: - this is a paper laying out how we could circumvent some major (both commercial and FOSS) IDPS solutions in their at the time of testing latest versions, by various combinations of extension headers and fragmentation: https://www.ernw.de/download/eu-14-Atlasis-Rey-Schaefer-briefings-Evasion-o…. - here's some thoughts and preliminary results of tests performed to circumvent stateless ACLs: http://www.insinuator.net/2015/01/evasion-of-cisco-acls-by-abusing-ipv6-dis…. http://www.insinuator.net/2015/01/the-persistent-problem-of-state-in-ipv6-s…. We have a (somewhat) ongoing research project looking more closely on the interaction of ACLs and extension headers. For the moment I can only state that it's not just Cisco who are "affected". More results will be available in some months. If the chairs consider this appropriate we will happily give a presentation on this stuff in Bucharest or at another occasion. We could even bring some devices to Bucharest to do some practical testing and demos "in some side room" during #RIPE71, for those interested. We can even do the latter without any official part in a session, if there's interest. As for the topic itself I'd like to summarize our position as follows: - it has not happened in the past 17 yrs (since publication of RFC2460) that compelling, Internet-scale use cases of extension headers have been brought up. - we're hence quite sceptical as for the "we might see cool use cases in 15-20 yrs" position someone expressed at the mic. - from a security perspective they turn out to be a nightmare for (a number of) current security architectures and controls. it is hence understandable (and we actually advise to do so) that they are blocked at the _border_ of networks that have not yet managed to identify a compelling use case. - looking at the "liberty" RFC2460 provides as for ext_hdrs (wrt to their number, order, options, fragmentable vs. unfragmentable part etc.) we do not expect that type of security issues to disappear soon (the main reason why we did not continue the IDPS research was that the involved student eventually delivered this thesis. one can probably find much more issues provided time & resources). Adding more parsing cycles & intelligence (read: silicon) is not an option, at least not for sth that doesn't have a use case. - the results of this (blocking) approach have been observed and documented by Jen & Fernando and others (Tim Chown). - now that "this vicious circle" has gained sufficient ground it will be even less incentivized to develop a compelling use case. which is why we do not expect to see one in the future. === Everybody have a great weekend and for those still in AMS: have a safe trip home! Best Enno -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator =======================================================

16 43

[training] RIPE NCC Webinars - new dates
by Training Services 18 Jun '15

18 Jun '15

Dear colleagues, We are pleased to announce the dates for the RIPE NCC Webinars for the coming quarter. These interactive on-line learning sessions take about one hour, and give you the opportunity to learn and interact with our trainers without leaving your desk. In the next 3 months you can participate in the following Webinars: - Advanced RIPE Atlas Usage (NEW!) - Introduction to the RIPE Database - RIPE Database - Advanced Topics - IPv6 in the RIPE Database - IPv6 Addressing Plan - Webinar for New LIRs - Resource Certification (RPKI) Register now at https://www.ripe.net/support/training/learn-online/webinars Participation is limited to 20 people, so don't hesitate if you want to take part! If you have any questions, please email <training(a)ripe.net>. We look forward to seeing you online. Kind regards, RIPE NCC Training Services

1 0

[news] Finnish IPv6 Launch Event on 8 June in Helsinki, Finland
by Marco Hogewoning 16 Jun '15

16 Jun '15

Dear colleagues, Finnish IPv6 Launch Event on 8 June in Helsinki, Finland On Tuesday 8 June, Viestintävirasto, the Finnish telecoms regulator, hosted a seminar on the launch of IPv6 in Finland across a broad spectrum of sectors. Emile Aben and I participated in this meeting on behalf of the RIPE NCC. This half-day meeting was the pinnacle of a project that started about two years ago with a renewal of the work programme of the national IPv6 task force. This renewal led to efforts to coordinate the deployment of IPv6, with the seminar date set as a milestone by which to achieve nationwide support for IPv6. The project found support from all major access providers as well as hosting companies and content providers including the national broadcaster, YLE, and MTV. We are pleased to see this strategy has paid off: the regulator estimates that approximately five million Finnish Internet connections are IPv6 enabled to date. Real-time measurements by APNIC also showed a rapid increase of IPv6 users over the preceding week: the percentage of end users observed using IPv6 quickly rose from almost nothing to 4.7%. DNA achieved the most spectacular deployment: the percentage of their customers using IPv6 skyrocketed to 16% and is still increasing. During the seminar, various operators reported on their experiences during the deployment. They also looked forward to resolving any remaining issues and using the knowledge gained to further advance IPv6 adoption throughout the country. More information about the initiative can be found at http://ipv6nyt.fi. For detailed statistics on the IPv6 deployment, see: http://stats.labs.apnic.net/ipv6/FI?c=FI&x=1&p=0&r=1&w= Regards, Marco Hogewoning -- External Relations - RIPE NCC

1 0

Re: [ipv6-wg] [v6ops] Extension Headers / Impact on Security Devices
by Mark ZZZ Smith 16 Jun '15

16 Jun '15

From: Ca By <cb.list6(a)gmail.com> To: Eric Vyncke (evyncke) <evyncke(a)cisco.com> Cc: "v6ops(a)ietf.org" <v6ops(a)ietf.org>; "ipv6-wg(a)ripe.net" <ipv6-wg(a)ripe.net> Sent: Tuesday, 16 June 2015, 8:32 Subject: Re: [v6ops] Extension Headers / Impact on Security Devices On Monday, June 15, 2015, Eric Vyncke (evyncke) <evyncke(a)cisco.com> wrote: Enno, As you probably know, Cisco handles PSIRT issues with care, so, I have no clue on this specific advisory. My own (educated) guess is that the packet causing a LC reload is fully RFC 2460 compliant but unusual, so, probably (a guess again) a combination of extension headers triggering a bug. In this specific case, I would not blame IPv6 or RFC 2460 but rather my own company (even if the affected versions were quite old as new IOS-XR versions appear to be immune to this bug). And I appreciate the humor in your rhetorical question about which FW could protect a CRS... Air gap probably :-) More generally, regarding the 'parsing of the header' and performance, my understanding (and I am NOT a HW engineer) is that there are multiple ways to parse the header chain: - purely software in low-end devices, should have a marginal performance impact - specific ASIC in middle-end devices (read high end enterprise), probably some limitations and heavy performance impact (but again within one organization, so, easier to fix the root cause) - a lot of specialized network processors in high-end devices (SP gears), which is a similar case as the 'low-end device', performance impact but marginal as parsing the chain of headers is not that hard after all _when_ coded correctly As the extension headers are specific to IPv6, this is an area when we will all learn (and have learned already) a lot of things... I respectfully disagree with your last sentence. Of course, destination AS/host SHOULD only accept useful, known and legit ext headers; but, why would an ISP filter on ext headers if they do not harm their own infra or a customer infra? Do you envision an Internet where only TCP/443 and UDP/43 would be accepted? Last point, the Internet will have to use IPv6 for 10 or 20 years at least. If the IETF/ISP block all new _options_ in _existing_ extension headers, then we will be stuck in 1997 for network innovation. While I do not like taking security risks, I even fear more the lack of innovation. I keep hearing this and it is very bizarre to hear With regards to 1997, believing that there will be innovation in the narrow waist of hour glass (network layer), that is very 1997. The network layer is stable and boring.... Hence it being narrow. Innovation is welcome everywhere except network in the e2e model / Absence of evidence is not evidence of absence. / Consider what the network and host situation was in 1997 (wired network access, desktops outselling laptops, dialup Internet for residential, corporates in total probably being the largest spenders on Internet access) to today and the near future (wireless networks, smartphones/tablets being the dominant Internet access device in some markets - and they're multi-homed, M2M/IoT considered to be place where the greatest expansion of Internet connected devices is going to occur in the near future.) / IPv6 has had relatively little adoption, and it is only starting to increase quite rapidly in the last few years and that is mainly because of mobile networks. There hasn't and still doesn't seem to be much thinking about how IPv6's differences from IPv4's can be taken advantage of yet - an "IPv4 first" or an "IPv4 == IPv6" mindset seems to be still very common (I think the network virtualisation space is where this is might be most prominent - I think most of the technologies they're inventing require fork lift network upgrades, so the costs of deploying IPv6 at the same time become a lot less significant. So if there is a "cheap" opportunity to deploy IPv6, and IPv6 is going to be the long term network layer 3, why not optimise for it now? That was the thinking behind my "Enhancing Virtual Network Encapsulation with IPv6" draft) / We don't want to disable innovation opportunities that IPv6 may provide before people have arrived at an "IPv6 first" or "IPv4 != IPv6" mindset. Let's talk on Thursday at Silvia's IPv6 Conference in Zurich ;-) -éric On 11/06/15 11:58, "Enno Rey" <erey(a)ernw.de> wrote: > >the problem here is the definition of "normal IP packet" as of RFC2460. >To illustrate this I just quote from today's Cisco advisory (Cisco IOS XR >Software Crafted IPv6 Packet Denial of Service Vulnerability) on packets >potentially crashing CRS-3 line cards: > >"The vulnerability is due to incorrect processing of an IPv6 packet >carrying IPv6 extension headers that are valid but unlikely to be seen >during normal operation. An attacker could exploit this vulnerability by >sending such an IPv6 packet to an affected device that is configured to >process IPv6 traffic. An exploit could allow the attacker to cause a >reload of the line card, resulting in a DoS condition." > >two question come to mind here: > >- is a "valid but unlikely" extension header chain "normal"? >- what ("combination of FW & IPS or whatever") would you put in front of >a CRS? > >my (sad) expectation is that we'll see much more of these (types of) >issues in the future. given the current level of freedom that the RFC2460 >leaves (see also discussion/picture in >http://www.insinuator.net/2015/06/is-ipv6-more-secure-than-ipv4-or-less/) >"properly parsing an IPv6 packet, let alone in wire speed" seems a pretty >much unsolvable task to me. > >That said I still fail to see any useful extension header besides AH&ESP >(not even FH) to be transported in the Internet. > >best > >Enno > > > > > > > > If your firewall cannot implement this policy, then >> it is time to change or to use a combination of FW & IPS or whatever. >> >> - network person: as I will live with IPv6 for the rest of my life, >>then I >> want a way to extend it and I need any packet to travel to my source to >>my >> destination. Any IPv6 packet should be able to traverse the >> Internet/private network as long as its layer-3 header is valid >> (filtering/dropping can be done exceptionally for good operational >> reason). Did we remember the IPv4 teardrop attack? It is blocked by >> default by most routers for years ;-) >> >> Bugs will plague us for ever... And make our life more complex than the >> above description of course ;-) >> >> -??ric >> >> On 17/05/15 20:43, "Silvia Hagen" <silvia.hagen(a)sunny.ch> wrote: >> >> >Hi >> > >> >I keep stumbling about that "recommendational wording" in RFC 2460 >> >everytime I teach it. >> > >> >Couldn't we update RFC2460 and make this list a strict order? >> > >> >I would want my firewall to notify me if the EHs in a packet do not >> >follow the list. >> >And limiting the number of possible EHs per packet might be a good >>idea. >> > >> >Silvia >> > >> >-----Urspr??ngliche Nachricht----- >> >Von: ipv6-wg [mailto:ipv6-wg-bounces@ripe.net] Im Auftrag von Benedikt >> >Stockebrand >> >Gesendet: Sonntag, 17. Mai 2015 18:39 >> >An: ipv6-wg(a)ripe.net >> >Betreff: Re: [ipv6-wg] Extension Headers / Impact on Security Devices >> > >> >Hi Enno and list, >> > >> >Enno Rey <erey(a)ernw.de> writes: >> > >> >> hope everybody had a great #RIPE70 meeting. We did! >> >> Many thanks to the organizers and chairs! >> > >> >and thanks to the actual speakers as well the speakers we had to turn >> >down due to time constraints, too:-) >> > >> >> If the chairs consider this appropriate we will happily give a >> >> presentation on this stuff in Bucharest or at another occasion. >> > >> >Sounds good to me! >> > >> >> - looking at the "liberty" RFC2460 provides as for ext_hdrs (wrt to >> >> their number, order[...] >> > >> >Actually, as far as I'm concerned that's the real core of the problem. >> >Or more specifically, the first two lines of RFC 2460, section 4.1: >> > >> > When more than one extension header is used in the same packet, it >>is >> > recommended that those headers appear in the following order: >> > >> >followed on the next page by >> > >> > Each extension header should occur at most once, except for the >> > Destination Options header which should occur at most twice (once >> > before a Routing header and once before the upper-layer header). >> > >> >Note in particular that these are not even RFC 2119 "SHOULD" or >> >"RECOMMENDED" and such. >> > >> >The impact here is actually at least twofold: >> > >> >- It is impossible to implement this as a simple pipeline architecture >> > in hardware; at least for cases deviating from the "recommendations" >> > above this effectively becomes either excessively complex to >>implement >> > in hardware or an invitation to DoS when implemented in software on >>an >> > otherwise hardware router. >> > >> >- As I understand it, at least some of the issues you have found are >> > effectively based on violating the second paragraph quoted, making it >> > impossible to come up with a lower bound on how long the header chain >> > can actually get and therefore leading to the fragmentation related >> > attacks and similar you have discovered. >> > >> >The original idea was that the extension headers are processed strictly >> >in the order they occur, so one question to ask is if there is any >>valid >> >reason to violate these "recommendations" for other than malicious >> >purposes. >> > >> > >> >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/ >> > >> > >> > >-- >Enno Rey > >ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de >Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 > >Handelsregister Mannheim: HRB 337135 >Geschaeftsfuehrer: Enno Rey > >======================================================= >Blog: www.insinuator.net || Conference: www.troopers.de >Twitter: @Enno_Insinuator >======================================================= > >_______________________________________________ >v6ops mailing list >v6ops(a)ietf.org >https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops(a)ietf.org https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops(a)ietf.org https://www.ietf.org/mailman/listinfo/v6ops

1 0

Looking for info on IGP choices in production dual-stack networks
by Victor Kuarsingh 09 Jun '15

09 Jun '15

RIPE IPv6 Folks: Philip Matthews and I are co-authors on an active draft within the IETF related to IPv6 routing design choices. To ensure we are gathering sufficient data we are looking for an expanded set of input from operator forums as well (vs. just the v6ops IETF list). The draft is found here -(https://tools.ietf.org/html/draft-ietf-v6ops-design-choices). We are looking for information on the IGP combinations people are running in their dual-stack networks. We are gathering this information so we can document in our draft which IGP choices are known to work well (i.e., people actually run this combination in production networks without issues). The draft will not name names, but just discuss things in aggregate: for example, "there are 3 large and 2 small production networks that run OSPF for IPv4 and IS-IS for IPv6, thus that combination is judged to work well". If you have a production dual-stack network, then we would like to know which IGP you use to route IPv4 and which you use to route IPv6. We would also like to know roughly how many routers are running this combination. Feel free to share any successes or concerns with the combination as well. We are looking particularly at combinations of the following IGPs: IS-IS, OSPFv2, OSPFv3, EIGRP. If you run something else (RIP?) then we would also like to hear about this, though we will likely document these differently. [We suspect you run RIP/RIPng only at the edge for special situations, but feel free to correct us]. And if you have one of those modern networks that carries dual-stack customer traffic in a L3VPN or similar and thus don’t need a dual-stacked core, then please email us and brag ... If you are on multiple lists at RIPE, NANOG or the IETF, we apologize for any redundant emails you may get (we are just attempting to reach the widest audience possible). Philip Matthews Victor Kuarsingh

1 0

New on RIPE Labs: IPv6 Deployment in Estonia
by Mirjam Kuehne 04 Jun '15

04 Jun '15

Dear colleagues, In case you missed Tarko Tikan's description of the IPv6 deployment in Estonia on other lists, we put the story on RIPE Labs: https://labs.ripe.net/Members/tarko_tikan/ipv6-deployment-in-estonia Kind regards, Mirjam Kuehne RIPE NCC

1 0

IPv6 only as default for next meeting
by Jérôme Fleury 24 May '15

24 May '15

During WG this afternoon, the idea was submitted that the IPv6 only experimentation be made the default SSID for the next meeting. While this has been working tremendously well for routine internet usage, I've been unable to use this network mainly because of incompatibility with my VPN network. We have a dual-stack VPN. some of the resources are v4 only though. The DNS64 converts my v4 VPN resources into v6 resources that are then routed to the non-VPN interface. While there could be workarounds (DNS64 on the VPN side, full v6 routing on the VPN, or all VPN resources available on v6) I don't think the technology is mature enough to make it the default for advanced usage. My 0.02$

11 18

How to Unsubscribe!?
by Adem Karatepe 15 May '15

15 May '15

Hi folks, I used to work in IPV6 work group before in my company and my colleague add me to this list but I'm not working on this group anymore and my colleague resigned from company so we don't have login details and we can not unsubscribe from the mail list. Is there any other way to unsubscribe? Adem Karatepe BT Proje Asistanı Project Support Staff Yazılım Geliştirme Direktörlüğü Software Development www.turksat.com.tr<http://www.turksat.com.tr> akaratepe(a)turksat.com.tr<mailto:akaratepe@turksat.com.tr> Gazi Üniversitesi Gölbaşı Yerleşkesi Teknoparkplaza kat 2 06830 Gölbaşı/ANKARA T : +90 312 497 47 00 F : +90 "Bu mesaj ve ekleri mesajda gönderildiği belirtilen kişi ya da kişilere özel olup gizli bilgiler içeriyor olabilir. Mesajın muhatabı ilgilisi ya da gönderileni değilseniz lütfen mesajı herhangi bir şekilde kullanmayınız çoğaltmayınız ve başkalarına ifşa etmeyiniz. Eğer mesaj yanlışlıkla size ulaşmışsa anılan mesaj ve ekinde yer alan bilgileri gizli tutunuz ve mesajı gönderen kişiyi bilgilendirerek söz konusu mesaj ile eklerini derhal imha ediniz. Bu mesaj ve ekindeki belgelerin bilinen virüslere karşı kontrolü yapılmıştır. Ancak e-posta sistemlerinin taşıdığı risklerden dolayı şirketimiz bu mesajın ve içerdiği bilgilerin size değişikliğe uğrayarak veya geç ulaşmasından bütünlüğünün ve gizliliğinin korunamamasından virüs içermesinden ve herhangi bir sebeple bilgisayarınıza ve sisteminize verebileceği zararlardan sorumlu tutulamaz.”<<<<< “This message together with its attachments is intended solely for the address(es) and may contain confidential or privileged information. If you are not the intended recipient please do not use copy or disclose the message for any purpose. Should you receive this message by mistake please keep all information contained in the message or its attachments strictly confidential and advise the sender and delete it immediately without retaining a copy. This message and its attachments have been swept by anti-virus systems for the presence of known viruses. However due to the risks of e-mail systems our company cannot accept liability for any changes or delay in receiving loss of integrity and confidentiality containing viruses and any damages caused in any way to your computer and system recipient, you are notified that disclosing, distributing, or copying this e-mail is strictly prohibited. “

1 0

Chair replacement procedure for ipv6-wg
by Dave Wilson 15 May '15

15 May '15

Hi all, You might remember from the last RIPE meeting that each working group had to finalise chair selection procedures. Because we were changing chairs anyway, ipv6-wg got to wait for one more meeting. Since the other working groups have gone through that process, however, we can use that to our advantage. Instead of starting from scratch, we propose to use a procedure which has already been discussed by a working group. The one we've chosen, because it seems very close to what we discussed at RIPE 69, is the procedure used by anti-abuse-wg. I hope this draft is already "good enough" for us to adopt as a result; if so, it'll save us repeating work that's already been done several times over in other WGs. We have this on the agenda for RIPE 70, and I hope we'll be able to adopt it then. Best regards, Dave ===(cut here)=== Note on Language: Throughout this document the word Chair shall be used for both Chairs and Co-Chairs. ** Introduction: This document outlines procedures dealing with the tenure of RIPE Working Group Chairs. It applies to all RIPE Working Groups. ** WG Chair Term: The term of a WG Chair is three years. A current chair may stand for re-selection at the end of their term. A WG Chair may resign voluntarily at any time. ** Selection of a WG Chair: WG Chair vacancies, along with a call for candidates, must be announced on the WG mailing list at least one month in advance of the date upon which the selection will be held. The announcement should set a closing date for candidates. A WG may request that a WG Chair vacancy be opened so long as the addition of a new Chair would not cause the number of Chairs of that WG to exceed three. WG Chairs are elected at WG sessions at RIPE meetings. Anyone physically present at the WG session is eligible to participate in the selection process. The candidate does not need to be physically present at the WG session. If possible the Chair should be elected by acclamation by the WG or by consensus after discussion. If the result is unclear, then a secret ballot should be held. In the case of a ballot, votes will be counted by RIPE NCC Staff and/or Chairs of other WGs. The result will be determined by simple majority. ** Removal of a WG Chair: A WG Chair may be unable to fulfil their duties as described in this document or otherwise fail to serve the WG and the community. With the endorsement of a significant share of the WG, a vote of no confidence may be initiated. Before a vote of no confidence is taken, due effort should be made to address the issue(s) leading to the vote. The right of reply must be given to all parties involved in the procedure. If this effort fails to resolve the issue, the vote may proceed. The vote must be requested on the WG mailing list at least one week in advance of the WG Session at a RIPE meeting and should take place during the WG session. Anyone physically present at the WG session may take part in the vote. The vote should be conducted by secret ballot and votes counted by RIPE NCC Staff and/or WG Chairs of other WGs. The result will be determined by simple majority. If the vote of no confidence in a WG Chair is passed, the seat is vacated and the WG Chair is not eligible for stand for re-selection. ** No Chair: If a working group is left with no Chair, e.g. due to the resignation or removal of the sole WG Chair, then the WG may elect an interim WG Chair according to the selection procedures specified above, but with candidates nominated at the WG session. An interim WG Chair must resign at the next WG session, but may stand for re-selection. ** Staggered Introduction: For the purposes of staggering the introduction of this policy, in the case where all co-Chairs of a WG have served for more than the standard WG Chair term limit, an optional waiver is given to these WGs to allow them to schedule the automatic resignations of their Chairs over the two RIPE meetings immediately following the adoption of this policy. If the WG decides to avail of this waiver, it is the responsibility of the WG to decide in what order its co-Chairs should stand down. ===(cut here)=== -- Dave Wilson, Service Desk Manager web: www.heanet.ie HEAnet Ltd, 5 George's Dock, IFSC, Dublin 1 tel: +353-1-660-9040 Registered in Ireland, no 275301 fax: +353-1-660-3666

5 6

Link to publicly available DNS64/NAT64 implementations
by Jan Zorz 14 May '15

14 May '15

Dear IPv6 WG, As promised during the IPv6 WG meeting at RIPE70, I'm sending the link with information how to test remotely different implementations of NAT64 that we are running in Go6lab: http://go6lab.si/current-ipv6-tests/nat64dns64-public-test/ Ecdysis is the weakest one and somehow a bit buggy, so please use the PAN and C1000 ones, that are dedicated boxes for this test and *will* handle the traffic and translation process ;) Cheers, Jan Zorz

4 3

Fwd: Re: IPv6-only network at RIPE70
by Wilfried Woeber 14 May '15

14 May '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Forgot to also include the wg mail list. sorry. Here you go, Wilfried. - -------- Forwarded Message -------- Subject: Re: [ipv6-wg] IPv6-only network at RIPE70 Date: Thu, 14 May 2015 11:50:07 +0200 From: Wilfried Woeber <woeber(a)cc.univie.ac.at> To: Jen Linkova <furry13(a)gmail.com> Hi Jen, v6-folks, > General feedback (do you guys see any value in such an experiment, > what was your experience etc) is appreciated. I was on this network while doing stuff after yesterday's key signing party, and it simply works, to fetch keys from servers and to upload. Just a minor thing and not too important for the "masses", but still thumbs-up :-) Wilfried -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVVQcKAAoJEPMGt0I/M2zSbX4P+waEJREbW9GoozrhpZov584V lKG5PKQGDRmLLvroF95Xr/KCKSMVwkOeE1Sizelh6uJXYkbnNpCCMifSg495SQY1 Oug/v0f6trhv03FpmQIKtpy2Jj9A3Vz6SislNbGFuvCB0T6LwV8vH1SKmGUdBeKX UoA8VfymQ6PGTOe2JsbIc6r3mdIhw9vjUeXYvoshEcItYmDYjrkXEELEO+YLpv88 8InaUVtlS1x5GR5M7DTaFhCjBaUPlEt9HXBk0BBg/6E+xXwaOU8JbtKq4yiifRH8 EjIEjsl77NGuhtlVPuUDmdq+pZ+Lgx9Sf1s0w7qOhQPxQI18EvnbqR0gVMZT0XGg PZjMt3W4AhktjXcwnS0bctCC+fdWYDK4YoxxhT9m9use94mj76Qk7BNMqyGKNJgF R9MFwps5pvVzykpoL0kHiIrfeN09EWMzjNTu+N5xUzu5KF4N3W431aYqsg4bFB64 mEbfzXbI7UBx7PYfCoGIvWwX+9Z4SM7MoO+FtZv/Bo/nXBP1X9nml2H3w0xYf7+R 2rOTciNesi9u1Mp0HCh6q0IUrijviw0QgdR7+fHYw7MDSbHmYaCO2ZGGDI8AVKjR aTf6Y6JZTr/WcH+nC18/Ix8gX88p8HfJT2bAsHVvmsAc5kzXxjlbklDFxMjYjV6i TaC7zIrY992Wt5ZXXFJc =FBOo -----END PGP SIGNATURE-----

1 0

IPv6-only network at RIPE70
by Jen Linkova 13 May '15

13 May '15

I'm glad to announce that there is a IPv6-only (with NAT64) network at RIPE70. Please note that this experimental network is not supported by the RIPE NCC or RIPE 67 Technical Team and is offered on a best-effort basis. How to connect: - Make sure IPv6 is enabled on your device - Connect to SSID: IPV6ONLYEXP - Enter the password: iknowbesteffort Please note that NAT64&DNS64 is used to provide connectivity to IPv4-only resources, so use DNS servers information provided by the network. If you see any connectivity issues: - connect to the 'normal' dual-stack one; - if connecting to dual-stack network solves the issue, please email me (furry13(a)gmail.com) with details, I'd love to know about any problems. General feedback (do you guys see any value in such an experiment, what was your experience etc) is appreciated. -- SY, Jen Linkova aka Furry

3 6

[training] RIPE NCC Training Courses July-September 2015
by Training Services 11 May '15

11 May '15

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 Frankfurt, London, Skopje, Stockholm, Minsk, Sarajevo, Vladivostok, Tel Aviv, Tallinn, Zurich, Paris, 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 - Database Training Course - Basic IPv6 Training Course - 2 day Advanced Training Course - Routing Security Training Course For more information visit: https://www.ripe.net/support/training/courses With kind regards, Rumy Spratley-Kanis Training Services Manager

1 0

RIPE70 Draft Agenda
by Jen Linkova 14 Apr '15

14 Apr '15

Dear IPv6 WG members, RIPE70 is less than a month away and IPv6 WG is going to have two sessions, both on Thu, May 14th: - session #1: 09:00 - 10:30 (overlaps with DNS WG session); - session #2: 16:00 - 17:30 (overlaps with Database WG session). Please find the draft agenda below. NB: This time we are planning to have some informal discussion on IPv6 deployment bumps so please, please get ready to actively participate in the session! === Session 1, Thu, May 14th, 9:00 - 10:30 === A. Administrativia B. "HTTP state management (cookie) in an IPv6 world: apply caution!", Eric Vynke C. “Use Cases for IPv6 Extension Headers - Let's do some Marketing”, Wilhelm Boeddinghaus D. "OS Behavior in Contradicting Environments" , Enno Rey E. “IPv6 for ISP”, Aaron Hughes === Session2, Thu, May 14thm 16:00 - 17:30 === A. Administrativia B. WG Chair replacement procedure discussion C. "IPv6 - who is and who isn't" Geoff Huston D. Lighting talks: d1. "Lost stars”, Natalie Trenaman, d2. “Software & IPv6”, Natalie Trenaman d3. "554,631 - what's the next IPV6 speed-bump?" Jan Zorz E. IPv6 deployment bumps discussion/brainstorming session === If you have any questions/comments/concerns please do not hesitate to contact WG chairs (ipv6-wg-chairs(a)ripe.net) or reply to this email. -- SY, Jen Linkova aka Furry - on behalf of IPv6 WG chairs.

1 0

What to do with RIPE Atlas probes that have only a ULA as IPv6 address?
by Philip Homburg 27 Mar '15

27 Mar '15

Dear community members, The RIPE Atlas team has a question what to do with probes that have only a Unique Local IPv6 Unicast Address (ULA) [RFC4193] as their IPv6 address. The question is whether to treat those probes as IPv6 capable or not. It is known that about 10% of the RIPE Atlas probes that have IPv6 addresses do not actually have IPv6 connectivity. This was documented by Stéphane Bortzmeyer in his RIPE Labs article "How Many RIPE Atlas Probes Believe They Have IPv6 (But Are Wrong)?" (https://labs.ripe.net/Members/stephane_bortzmeyer/how-many-atlas-probes-bel…) As a way of dealing with this problem, the RIPE Atlas system now tags probes that have broken IPv6. Any probe that has an IPv6 address (other than link local) but cannot reach the global internet is tagged as "IPv6 Doesn't Work" (see https://atlas.ripe.net/docs/probe-tags/) At the moment, around 2800 probes are connected and have an IPv6 address. Of those probes, around 350 (12.5%) are tagged that IPv6 doesn't work. Of those 350 probes, 114 have the surprising condition that the connect system call fails immediately with the error 'Network is unreachable.' Those 114 probes have two things in common, they have only a ULA address and the do not have a default route. It is the lack of default route that causes the connect system call to fail immediately. This feature (ULA and no default route) is specified in RFC-7084 (IPv6 CE Router Requirements) requirement ULA-5 ("An IPv6 CE router MUST NOT advertise itself as a default router with a Router Lifetime greater than zero whenever all of its configured and delegated prefixes are ULA prefixes.") The surprising thing is that for some probes this condition persists for many months. For the Atlas project, the question is how we should treat these probes. Currently they are regarded as having broken IPv6 connectivity. However, an alternative is to consider those probes as having no IPv6 at all. Broader questions are: are CPEs doing the right thing here. Should a CPE announce a ULA on the local LAN even if there hasn't been any IPv6 internet connectivity for a very long time? It is already complex enough for normal users to understand that there is always a link local IPv6 address even if there is no IPv6 connectivity. Now we have to add ULA to that group as well. So the question to the community, should RIPE Atlas treat ULAs in the same way as RFC-1918, addresses that should be ignored unless a valid global address can be found elsewhere. Or should we keep the current approach where ULAs are treated just like other global IPv6 addresses and consider the probe host's network setup to be broken? Philip

15 26

[training] RIPE NCC Webinars - new dates
by Olivia Mijnals-Ruimwijk 27 Mar '15

27 Mar '15

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://lirportal.ripe.net/training/courses 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] What to do with RIPE Atlas probes that have only a ULA as IPv6 address?
by Geert Jan de Groot 26 Mar '15

26 Mar '15

As to the ATLAS-ULA discussion, here is a datapoint that may be interesting to some. After some network changes / upgrades, my probe was not happy with IPv6. For the built-in measurements, IPv4 was fine but all the IPv6 measurements were showing on-off behaviour with a cycle time of 2 hours. Initially I had no clue what was happening. Set up various IPv6 ping tests to the probe, and they were clean, and the measurements still showed the same outages. Also, measurements to other SLAAC clients were also spotless. While I was investigating something else however, I noticed these packets on the VDSL PPPoE-link to the ISP: 15:25:39.366673 IP6 fd0c:8f98:a1d2:80:6666:b3ff:fec5:dee.54536 > 2001:500:2d::d .53: 61413 TXT CHAOS? hostname.bind. (31) 15:25:41.911297 IP6 fd0c:8f98:a1d2:80:6666:b3ff:fec5:dee.46086 > 2001:500:2::c. 53: 64278 TXT CHAOS? hostname.bind. (31) Note the source address of these packets. Indeed, looking at the ATLAS portal, both the public IPv6 IP and ULA IP was listed on the info page of my probe, and the ULA IP didn't have connectivity. I diked out the ULA config on the OpenWRT router (not sure how it got there, probably PEBCAK but I didn't explicitely configure it), and things are a lot better now. Thanks to Philip for spotting the problem, Geert Jan

1 0

New Document Published - RIPE-631, IPv6 Troubleshooting for Residential ISP Helpdesks
by Nathalie Trenaman 26 Feb '15

26 Feb '15

Dear colleagues, I’m happy to announce we just published a new RIPE Document called "IPv6 Troubleshooting for Residential ISP Helpdesks”. This document serves as a best current operational practice for helpdesks at residential Internet service providers that offer IPv6 to their customers. The full text is available at: https://www.ripe.net/ripe/docs/ripe-631 The PDF version of this document was designed to have an easy-to-read layout so it can be kept close at hand and used as a reference document. Many thanks to the authors: Lee Howard, John Jason Brzozowski, David Freedman, Jason Fesler, Tim Chown, Sander Steffann, Chris Grundemann, Jen Linkova, Chris Tuska, Daniel Breuer, Jan Žorž, and everybody else in the community who contributed to this text. We would also like to thank the RIPE NCC staff who helped edit and publish the document. Best regards, Nathalie Künneke-Trenaman IPv6 Program Manager RIPE NCC

1 0

[training] RIPE NCC Training Courses April-June 2015
by Training Services 17 Feb '15

17 Feb '15

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 Tashkent, Lisbon, Poznan, Belgrade, Manchester, Kuwait, Helsinki, Dublin, Nicosia, Kazan, Amsterdam, Vienna, Hamburg. 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: - Local Internet Registry (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-wg Digest, Vol 41, Issue 2
by behroz abbaszadeh 08 Feb '15

08 Feb '15

Thank You very Much I will Appreciate if you can Share the PDF version of Materials. Thank you Behrouz -------------------------------------------- On Thu, 2/5/15, ipv6-wg-request(a)ripe.net <ipv6-wg-request(a)ripe.net> wrote: Subject: ipv6-wg Digest, Vol 41, Issue 2 To: ipv6-wg(a)ripe.net Date: Thursday, February 5, 2015, 2:30 PM 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. IPv6-only network & Android 5 (Colin Petrie) 2. ipv6-wg Digest, Vol 41, Issue 1 (behroz abbaszadeh) 3. Re: ipv6-wg Digest, Vol 41, Issue 1 (Nathalie Trenaman) ---------------------------------------------------------------------- Message: 1 Date: Wed, 04 Feb 2015 13:55:35 +0100 From: Colin Petrie <cpetrie(a)ripe.net> To: ipv6-wg(a)ripe.net Subject: [ipv6-wg] IPv6-only network & Android 5 Message-ID: <54D216C7.9060709(a)ripe.net> Content-Type: text/plain; charset=ISO-8859-1 Hello, We thought you might be happy to know that the RIPE Meeting IPv6-only/nat64/dns64 network works with Android 5 (Lollipop) I tried this a few days ago on the meeting network kit in the lab here, using a stock 2012 Nexus 7 (which received a OTA update to Android 5 a couple of weeks ago). It uses RAs/SLAAC, plus RFC6106 for DNS options. Here is a link to the test-ipv6 results, from using Chrome while connected: http://isp.test-ipv6.com/?ip4=193.0.31.242&ip6=2001:67c:64:49:2cdb:4986:ce8… Glad to see one more major OS supporting V6-only networks! Regards, Colin -- Colin Petrie RIPE NCC ------------------------------ Message: 2 Date: Wed, 4 Feb 2015 22:44:46 -0800 From: behroz abbaszadeh <abbaszadehb(a)yahoo.com> To: ipv6-wg(a)ripe.net Subject: [ipv6-wg] ipv6-wg Digest, Vol 41, Issue 1 Message-ID: <1423118686.53039.YahooMailBasic(a)web125704.mail.ne1.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 I recommendation RIPE NCC to expand the training materials. For example Security in IPv6, APIs and .. Thank you ------------------------------------------ On Mon, 2/2/15, ipv6-wg-request(a)ripe.net <ipv6-wg-request(a)ripe.net> wrote: Subject: ipv6-wg Digest, Vol 41, Issue 1 To: ipv6-wg(a)ripe.net Date: Monday, February 2, 2015, 2:30 PM 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. [training] RIPE NCC Webinars - new dates (Training Services) ---------------------------------------------------------------------- Message: 1 Date: Mon, 02 Feb 2015 10:49:15 +0100 From: Training Services <training(a)ripe.net> To: ipv6-wg(a)ripe.net Subject: [ipv6-wg] [training] RIPE NCC Webinars - new dates Message-ID: <54CF481B.3000109(a)ripe.net> Content-Type: text/plain; charset=utf-8; format=flowed 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 End of ipv6-wg Digest, Vol 41, Issue 1 ************************************** ------------------------------ Message: 3 Date: Thu, 5 Feb 2015 09:36:01 +0100 From: Nathalie Trenaman <nathalie(a)ripe.net> To: behroz abbaszadeh <abbaszadehb(a)yahoo.com> Cc: ipv6-wg(a)ripe.net Subject: Re: [ipv6-wg] ipv6-wg Digest, Vol 41, Issue 1 Message-ID: <0A1753E8-84C0-4AA0-A2CE-4907A5D20071(a)ripe.net> Content-Type: text/plain; charset="iso-8859-1" Dear Behroz, Thank you for your feedback. We are constantly expanding our IPv6 training course portfolio. At this moment, we offer 2 different IPv6 webinars plus the Basic and Advanced IPv6 course and we are developing an IPv6 training course for the RIPE NCC Academy as we speak. The topic of IPv6 security is covered in our Advanced IPv6 training course. You can find all our training material here: http://www.ripe.net/lir-services/training/material With kind regards, Nathalie K?nneke-Trenaman IPv6 Program Manager RIPE NCC On 05 Feb 2015, at 07:44, behroz abbaszadeh <abbaszadehb(a)yahoo.com> wrote: > I recommendation RIPE NCC to expand the training materials. For example Security in IPv6, APIs and .. > Thank you > > ------------------------------------------ > On Mon, 2/2/15, ipv6-wg-request(a)ripe.net <ipv6-wg-request(a)ripe.net> wrote: > > Subject: ipv6-wg Digest, Vol 41, Issue 1 > To: ipv6-wg(a)ripe.net > Date: Monday, February 2, 2015, 2:30 PM > > 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. [training] RIPE NCC Webinars - new > dates (Training Services) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 02 Feb 2015 10:49:15 +0100 > From: Training Services <training(a)ripe.net> > To: ipv6-wg(a)ripe.net > Subject: [ipv6-wg] [training] RIPE NCC Webinars - new dates > Message-ID: <54CF481B.3000109(a)ripe.net> > Content-Type: text/plain; charset=utf-8; format=flowed > > 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 > > > > End of ipv6-wg Digest, Vol 41, Issue 1 > ************************************** > >

1 0