- ipv6-wg - mailman.ripe.net

IPv6 Best Practice Forum
by Michael Oghia 27 Jul '16

27 Jul '16

Dear colleagues, Building on last year's IGF Best Practice Forum (BPF) on creating an enabling environment for IPv6 <http://www.intgovforum.org/cms/documents/best-practice-forums/creating-an-e…>, we are now focusing this year's IPv6 BPF work on how to best encourage and support IPv6 adoption (for more information, see: Scope and Goals <http://www.intgovforum.org/cms/documents/best-practice-forums/798-scope-and…> ). The IPv6 BPF is a consensus-driven, bottom-up, and inclusive collaborative effort, one that brings together professional expertise from across stakeholder groups in order to generate a practical, constructive, and relevant outcome document. We are currently soliciting feedback and brainstorming ideas, especially related to economic elements of IPv6 adoption and business cases: https://docs.google.com/document/d/1C7z8MRVBOmBsuWxpl8YivXZWFvksKCq0_ul7TlF… If you are not already involved, I encourage you to add suggestions to the document, share it among your networks, and contact Izumi Okutani, our MAG coordinator, or Wim Degezelle, the IPv6 BPF project manager, for more information or if you have any questions. Additionally, you can sign up for the mailing list at: http://mail.intgovforum.org/mailman/listinfo/bp_ipv6_intgovforum.org. Kind regards, -Michael __________________ Michael J. Oghia iGmena <http://igmena.org/> communications manager Independent #netgov consultant & editor Istanbul, Turkey Skype: mikeoghia Twitter <https://www.twitter.com/MikeOghia> *|* LinkedIn <https://www.linkedin.com/in/mikeoghia>

1 0

Enterprise (Rabobank) on IPv6
by Sander Steffann 26 Jul '16

26 Jul '16

Hi, For those of you who need some serious examples of enterprises doing IPv6 so you can convince other enterprises: today there is a new example to follow, rabobank.nl :-) Rabobank is one of the largest banks of the Netherlands (and according to i.e. http://www.accuity.com/useful-links/bank-rankings/ even in the top-50 of largest banks in the world). Banks are often known for being cautious and conservative, so a major bank deploying IPv6 on their main website might take away some reluctance at other enterprises. Cheers! Sander

4 4

[members-discuss] manufacturers of routers and IPV6
by Куприянов Роман 25 Jul '16

25 Jul '16

Dear colleagues. Is there any possibility of the community affect the router manufacturer to implement the required functionality for the implementation of IPV6? ---------- Best regards, Kupriyanov Roman (ru.enigma)

5 4

New on RIPE Labs: Can You Make IPv6 Work Commercially?
by Mirjam Kuehne 07 Jul '16

07 Jul '16

Dear colleagues, Large scale IPv6 deployments suggest that IPv6 is at least a technical success, the technology works. Time to visit the other important question: does it work commercially. Does IPv6 really come with a positive business case? We are about to find out, if you help us... Read more on RIPE Labs: https://labs.ripe.net/Members/marco_hogewoning/can-you-make-ipv6-work-comme… Please also note the poll next to the article. Kind regards, Mirjam Kuehne RIPE NCC

1 0

Fwd: [v6ops] RFC 7872 on Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World
by Fernando Gont 28 Jun '16

28 Jun '16

FYI -------- Forwarded Message -------- Subject: [v6ops] RFC 7872 on Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World Date: Tue, 21 Jun 2016 16:57:35 -0700 (PDT) From: rfc-editor(a)rfc-editor.org To: ietf-announce(a)ietf.org, rfc-dist(a)rfc-editor.org CC: v6ops(a)ietf.org, rfc-editor(a)rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 7872 Title: Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World Author: F. Gont, J. Linkova, T. Chown, W. Liu Status: Informational Stream: IETF Date: June 2016 Mailbox: fgont(a)si6networks.com, furry(a)google.com, tim.chown(a)jisc.ac.uk, liushucheng(a)huawei.com Pages: 15 Characters: 30924 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-v6ops-ipv6-ehs-in-real-world-02.txt URL: https://www.rfc-editor.org/info/rfc7872 DOI: http://dx.doi.org/10.17487/RFC7872 This document presents real-world data regarding the extent to which packets with IPv6 Extension Headers (EHs) are dropped in the Internet (as originally measured in August 2014 and later in June 2015, with similar results) and where in the network such dropping occurs. The aforementioned results serve as a problem statement that is expected to trigger operational advice on the filtering of IPv6 packets carrying IPv6 EHs so that the situation improves over time. This document also explains how the results were obtained, such that the corresponding measurements can be reproduced by other members of the community and repeated over time to observe changes in the handling of packets with IPv6 EHs. This document is a product of the IPv6 Operations Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor(a)rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ v6ops mailing list v6ops(a)ietf.org https://www.ietf.org/mailman/listinfo/v6ops -- Fernando Gont e-mail: fernando(a)gont.com.ar || fgont(a)si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 -- Fernando Gont SI6 Networks e-mail: fgont(a)si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

1 0

measuring the effects of happy eyeballs
by Bajpai, Vaibhav 22 Jun '16

22 Jun '16

Dear v6 WG, Measuring the Effects of Happy Eyeballs --------------------------------------- A paper on measuring the effects of happy eyeballs [RFC 6555] just got accepted last week. This uses a 3-years long ('13 - '16) dataset of TCP connect times towards ALEXA top 10K websites collected from 80 dual-stacked SamKnows probes. We just released [a] the paper. Thought to share it along: [a] http://goo.gl/JmKEax Feedback most welcome! You may recall preliminary versions of this work at RIPE 66 [b] and IETF 87 [c]. [b] https://ripe66.ripe.net/archives/video/1208 [c] https://vimeo.com/71407427 Abstract -------- The IETF has developed protocols that promote a healthy IPv4 and IPv6 co-existence. The Happy Eyeballs (HE) algorithm, for instance, prevents bad user experience in situations where IPv6 connectivity is broken. Using an active test (happy) that measures TCP connection establishment times, we evaluate the effects of the HE algorithm. The happy test measures against ALEXA top 10K websites from 80 SamKnows probes connected to dual-stacked networks representing 58 different ASes. Using a 3-years long (2013 - 2016) dataset, we show that TCP connect times to popular websites over IPv6 have considerably improved over time. As of May 2016, 18% of these websites are faster over IPv6 with 91% of the rest at most 1 ms slower. The historical trend shows that only around 1% of the TCP connect times over IPv6 were ever above the HE timer value (300 ms), which leaves around 2% chance for IPv4 to win a HE race towards these websites. As such, 99% of these websites prefer IPv6 connections more than 98% of the time. We show that although absolute TCP connect times (in ms) are not that far apart in both address families, HE with a 300 ms timer value tends to prefer slower IPv6 connections in around 90% of the cases. We show that lowering the HE timer value to 150 ms gives us a margin benefit of 10% while retaining same preference levels over IPv6. Best, Vaibhav =================================== Vaibhav Bajpai www.vaibhavbajpai.com Room 91, Research I School of Engineering and Sciences Jacobs University Bremen, Germany ===================================

1 0

Fwd: [Bp_ipv6] Starting IPv6 BPF 2016: Next call on 23rd June
by Michael Oghia 22 Jun '16

22 Jun '16

FYI. The IGF's Best Practice Forums provide tangible and useful outputs, and this year's IPv6 BPF aims to build on last year's momentum. I encourage anyone working with IPv6 to participate and spread this around your networks. Best, -Michael Oghia __________________ Independent #netgov consultant & editor 2015 ISOC IGF Ambassador Istanbul, Turkey Skype: mikeoghia Twitter <https://www.twitter.com/MikeOghia> *|* LinkedIn <https://www.linkedin.com/in/mikeoghia> ---------- Forwarded message ---------- From: Izumi Okutani <izumi(a)nic.ad.jp> Date: Tue, Jun 21, 2016 at 6:06 PM Subject: [Bp_ipv6] Starting IPv6 BPF 2016: Next call on 23rd June To: "bp_ipv6(a)intgovforum.org" <bp_ipv6(a)intgovforum.org> Dear Colleagues, We are starting work on IPv6 BPF 2016 and I am serving as a MAG Coordinator this year, with my colleague Sumon Ahmed Sabir. You can see our profiles at: http://www.intgovforum.org/cms/mag/45-mag-membership/3030-mag-2016-membersh… To start work for the BPF this year. we would like to invite you to: 1) Share your feedback on the attached Scope and Goals document for IPv6 BPF 2016 Close comments by: Fri 1st July 2) Join us in the call at UTC1600 Thu 23rd June *Register* < https://intgovforum.webex.com/intgovforum/j.php?RGID=ra8e66724ded8a366ee621… > After your request has been approved, you'll receive instructions for joining the meeting. To share some background, last year’s BPF on IPv6 focused on creating capacity building platforms and awareness raising, in the form of national and regional IPv6 taskforces and other initiatives. Building upon the conclusions of last year, the BPF on IPv6 organizers now suggest a focus on the economic decisions and commercial drivers behind the decision to adopt IPv6. Therefore, the target is non-technical people who can share economic/business perspectives. As we did last year, we would like to start with fixing the Scope and Goals document, to be the basis of our work for the output document to be produced as our BFP. Best Regards, Izumi Okutani _______________________________________________ Bp_ipv6 mailing list Bp_ipv6(a)intgovforum.org http://intgovforum.org/mailman/listinfo/bp_ipv6_intgovforum.org

1 0

Icon with IPv6
by Alexey Galaev 21 Jun '16

21 Jun '16

Hi all. Do anyone have isometric icon with IPv6 logo? We are creating animated form to order servers with IPv6. Now that looks like http://storage2.static.itmages.com/i/16/0621/h_1466530601_3472813_28e93c8b0… Thanks. Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

1 0

New on RIPE Labs: Reducing the BGP Table Size - A Fairy Tale
by Mirjam Kuehne 20 Jun '16

20 Jun '16

Dear colleagues, Please find a new article on RIPE Labs: George Michaelson is discussing the issue of the relative sizes of the IPv4 and IPv6 Internet in BGP.: https://labs.ripe.net/Members/ggm/reducing-the-bgp-table-size-a-fairy-tale?… Kind regards, Mirjam Kuehne RIPE NCC

1 0

Maximum acceptable IPv6 prefix in BGP table?
by Sergey 16 Jun '16

16 Jun '16

Hi, Looking at the BGP table I see stuff like this, not even /64: 2001:218:2000:5000::3a0/126 *[BGP/170] 2d 08:02:02, localpref 180 AS path: 12714 31133 3491 10026 I, validation-state: unverified > to 2a00:d18:fe03:fefe:a76d::1 via ae2.3386 As we can see this wasn't rejected by 3 AS-es. AFAIK, the minimum allocated space from RIRs is /48. Should we filter prefixes longer than this? -- Kind regards, CTO at *Foton Telecom CJSC (ru.fotontelecom)* Tel.: +7 (499) 679-99-99 AS42861 on PeeringDB <http://as42861.peeringdb.com/>, Qrator <https://radar.qrator.net/as42861>, BGP.HE.NET <http://bgp.he.net/AS42861> http://ipv6actnow.org/

9 14

Re: [ipv6-wg] Maximum acceptable IPv6 prefix in BGP table?
by Mark Tinka 15 Jun '16

15 Jun '16

On 15/Jun/16 11:39, Colin Petrie wrote: > We tried this out last year: > https://labs.ripe.net/Members/emileaben/has-the-routability-of-longer-than-… > > TL;DR - global usefulness of longer-than-/24 is still pretty low. Thanks, Colin. On my side, I'm not immediately keen to fill FIB slots with >/24 or >/48. But I'll keep an eye on what the rest of the community does and adjust accordingly if it makes sense. Mark.

1 0

RIPE Policy vs IETF RFC
by Nathalie Trenaman 14 Jun '16

14 Jun '16

Dear colleagues, As you might know, the current IPv6 policy states very clear that assignments to customers must be a minimum of a /64. 5.4.1. Assignment address space size End Users are assigned an End Site assignment from their LIR or ISP. The size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /64 (only one subnet is anticipated for the End Site). https://www.ripe.net/publications/docs/ripe-655 On the other hand, a while ago, RFC7608 (BCP198) was published, stating: 2. Recommendation IPv6 implementations MUST conform to the rules specified in Section 5.1 of [RFC4632]. Decision-making processes for forwarding MUST NOT restrict the length of IPv6 prefixes by design. In particular, forwarding processes MUST be designed to process prefixes of any length up to /128, by increments of 1. In practice, this means that the RFC suggests that a customer can get an IPv6 assignment of any size, while the RIPE policy says the minimum should be a /64. I’m interested to know what the community thinks about this and if alignment between this RFC and the RIPE policy is needed. Nathalie Künneke-Trenaman IPv6 Program Manager RIPE NCC

9 9

New on RIPE Labs: How are you Deploying IPv6? Take this Survey
by Mirjam Kuehne 31 May '16

31 May '16

Dear colleagues, For those of you who missed Jordi Palet's original announcement, his call for the IPv6 deployment survey is now also on RIPE Labs: https://labs.ripe.net/Members/jordipaletm/how-are-you-deploying-ipv6-take-t… Kind regards, Mirjam Kuehne RIPE NCC

1 0

v4 versus v6 -- who connects faster?
by Vaibhav Bajpai 23 May '16

23 May '16

Dear v6 WG, Here [a] is a toy v6 service I came up with during the RIPE Atlas hackathon over this weekend. Thought I share this along: [a] http://goo.gl/hbzbwD <http://goo.gl/hbzbwD> You enter a dual-stacked website (ALEXA top 10K) and it shows you the difference in TCP connect times over v4 and v6 as seen by all dual-stacked RIPE Atlas probes (~1.3K probes). You can also filter the visualisation from a specific origin-AS. This additional filter can be useful to view performance towards a website from a specific origin-AS (say DTAG). Disclaimer: This is an outcome of a 1.5d long hackathon project. As such, the codebase is possibly inundated with bugs. Please don’t see it as a production service :-) Best, Vaibhav =================================== Vaibhav Bajpai www.vaibhavbajpai.com <http://www.vaibhavbajpai.com/> Room 91, Research I School of Engineering and Sciences Jacobs University Bremen, Germany ===================================

6 11

v4 versus v6 -- who connects faster?
by Bajpai, Vaibhav 23 May '16

23 May '16

Dear v6 WG, Here [a] is a toy v6 service I came up with during the RIPE Atlas hackathon over this weekend. Thought I share this along: [a] http://goo.gl/hbzbwD You enter a dual-stacked website (ALEXA top 10K) and it shows you the difference in TCP connect times over v4 and v6 as seen by all dual-stacked RIPE Atlas probes (~1.3K probes). You can also filter the visualisation from a specific origin-AS. This additional filter can be useful to view performance towards a website from a specific origin-AS (say 3320). Disclaimer: This is an outcome of a 1.5d long hackathon project. As such, the codebase is possibly inundated with bugs. Please don’t see it as a production service :-) Best, Vaibhav =================================== Vaibhav Bajpai www.vaibhavbajpai.com<http://www.vaibhavbajpai.com> Room 91, Research I School of Engineering and Sciences Jacobs University Bremen, Germany ===================================

2 1

Re: [ipv6-wg] v4 versus v6 -- who connects faster?
by Eric Vyncke (evyncke) 23 May '16

23 May '16

Hello Vaibhav, The map with blue/red is really a nice one :-) May I dare to propose some improvements? * on the blue/red map, be sure to have blue meaning all the time that IPv6 is faster (the legend is unclear and by using those tools, I know that this is not trivial to do) * State the date of the 'scan' * Some web sites are in the top 10K of Alexa but are not in: www.iet.org, www.lesoir.be, .... (Even www.ripe.net is not in the data :-) but RIPE is only 25.000th so out of your data set) Again, nice visualisation! -éric From: ipv6-wg <ipv6-wg-bounces(a)ripe.net<mailto:ipv6-wg-bounces@ripe.net>> on behalf of "Bajpai, Vaibhav" <v.bajpai(a)jacobs-university.de<mailto:v.bajpai@jacobs-university.de>> Date: Monday 23 May 2016 at 08:08 To: "ipv6-wg(a)ripe.net<mailto:ipv6-wg@ripe.net> IPv6" <ipv6-wg(a)ripe.net<mailto:ipv6-wg@ripe.net>> Subject: [ipv6-wg] v4 versus v6 -- who connects faster? Dear v6 WG, Here [a] is a toy v6 service I came up with during the RIPE Atlas hackathon over this weekend. Thought I share this along: [a] http://goo.gl/hbzbwD You enter a dual-stacked website (ALEXA top 10K) and it shows you the difference in TCP connect times over v4 and v6 as seen by all dual-stacked RIPE Atlas probes (~1.3K probes). You can also filter the visualisation from a specific origin-AS. This additional filter can be useful to view performance towards a website from a specific origin-AS (say 3320). Disclaimer: This is an outcome of a 1.5d long hackathon project. As such, the codebase is possibly inundated with bugs. Please don’t see it as a production service :-) Best, Vaibhav =================================== Vaibhav Bajpai www.vaibhavbajpai.com<http://www.vaibhavbajpai.com> Room 91, Research I School of Engineering and Sciences Jacobs University Bremen, Germany ===================================

2 1

IPv6 residential deployment survey (looking into technical aspects)
by JORDI PALET MARTINEZ 20 May '16

20 May '16

Hi all, I got so much input for a small “email survey”, that I’ve decided to make it more complete and on-line. The results will be published and updated every month or so, I will provide ASAP the link to those stats. No personal data will be published. http://survey.consulintel.es/index.php/175122 (If you know your network, it takes less than 2 minutes to complete it) It can be responded even if is not yet a commercial service, and customers can also respond, not just the ISP. However, to avoid duplicate data, make sure to include the country and ISP name. For those that already replied to me by email, it will be much better if you can fill in the on-line survey. Otherwise, after a week or so, I will input “manually” the data that you provided, but then there will be many “empty” questions. Please, feel free to circulate this message as much as you can ! Thanks a lot! Regards, Jordi ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

1 0

New on RIPE Labs: IPv6 Fragmentation (by Geoff Huston)
by Mirjam Kuehne 19 May '16

19 May '16

Dear colleagues, Please find this new article on "Fragmenting IPv6" by Geoff Huston on RIPE Labs: https://labs.ripe.net/Members/gih/fragmenting-ipv6?pk_campaign=labs&pk_kwd=… Kind regards, Mirjam Kuehne RIPE NCC

1 0

IPv6 residential service: What prefix, static, dynamic, extra cost ?
by JORDI PALET MARTINEZ 19 May '16

19 May '16

Hi all, I’m trying to make a table to compare the way actual IPv6 services to residential customers are being provissioned mainly in EU, but I will do to the same also in other regions. I’m happy to make a single “table” with all the information that I can collect and publish it so others can make use of it, and keep it updated, may be in some URL, etc. So here are the questions for actual IPv6 services providers to residential customers: 1) What prefix size is provided? 2) Is that prefix static or dynamic? 3) In case is dynamic, there is a chance for static? 4) Any extra cost for having it static, or having a bigger prefix (i.e., /48 instead of /56)? 5) If the customer has already a static IPv4 with a monthly charge, is still IPv6 static prefix being charged on top of that? Please state the ISP name, country and if you have a URL or document that state this service, other options, etc. If you’re not yet providing the service, but it will happen soon and the “model” for this has been already defined, please let me know as well! Hopefully I can get a lot of anwers! Private or in the list, I’m fine either way. Thanks! Regards, Jordi PD: In my opinion it should be /48 by default, static and opt-in to dynamic, no extra charge on top of the Internet service price, but I know many ISPs will not agree :-( Here just trying to collect the info in a single place. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

15 21

Re: [ipv6-wg] IPv6 cloud!
by Benedikt Stockebrand 12 May '16

12 May '16

Hi Ole and list, "Ole Troan (otroan)" <otroan(a)cisco.com> writes: >> Considering the increasing reports of people having problems with >> DS-Lite > > Any more details on that? > New problems not mentioned in RFC6269? sorry I haven't got the time right now to review RFC6269 for what's exactly mentioned there and what isn't, but: When I do IPv6 trainings these days it's about one in eight who is struggling with their land line access, which is based on DS-Lite and which reasonably well matches the estimated percentage of DS-Lite on land lines. The problems are however of a somewhat different nature than what RFC6269 addresses; they are roughly these: - Various services don't work. Like STUN, and due to that, SIP. And apparently various VPN solutions, too, but I never got access to any details with this. The real culprit here seems to be restricted cone NAT in the AFTR, plus apparently IPsec not working through DS-Lite. - There have been multiple reports that during peak hours there are significant connection drops. The impact varies from user to user as well as from ISP to ISP, apparently. Or as one user put it: "I solved the problem. I just don't even try to access IPv4-only web pages on saturday afternoons any longer." I don't have access to the AFTRs involved, so I can't reliably tell what's happening there, but from the descriptions I got it looks like some of them are actually running out of memory/CAM during peak hours and start to drop the connections. This is economically plausible, too, since the ISPs won't spend significant money on AFTR hardware until problems have already shown up. - First level support is frequently completely helpless when confronted with DS-Lite, or even IPv6 in general. The most annoying aspect here is that frequently it comes across that "it's a problem with IPv6" and "if you keep complaining they'll switch it off again for you" (i.e. they go back to IPv4-only connectivity without restricted cone NAT). All the information I have here is largely based on anecdotal reports, but enough of them for me to consider these problems anything but isolated cases. 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/

3 4

Re: [ipv6-wg] ipv6-wg Digest, Vol 55, Issue 4 -NAT64 Benedikt Stockebrand
by Thorsten Trottier 05 May '16

05 May '16

Hello Benedikt, I’m not a friend of NAT as well, but demonize NAT for any actions is a kind of overdo, isn’t it. We are living with NAT a long time now for better or for worse. A customer of mine (enterprise customer with hundreds of sites and thousands of employees) has setup his IPv6 project more than 4 years ago and plans to be finished 2020. Their project team produced hundreds of pages in planning strategy, timeline and migration. In one of their sub projects they saw NAT as a interim solution for their Webservice as best method. We implemented a redundant NAT64 solution based on Cisco Adress Family Translation. Now IPv6-only or Dual-stacked Users can hit the customers web service which is still IPv4 only. Of course not a low-cost solution, but for „political" and/or technical reasons a solid way. Best regards Thorsten > > > -----Ursprüngliche Nachricht----- > Von: ipv6-wg [mailto:ipv6-wg-bounces@ripe.net] Im Auftrag von ipv6-wg-request(a)ripe.net > Gesendet: Dienstag, 26. April 2016 12:00 > An: ipv6-wg(a)ripe.net > Betreff: ipv6-wg Digest, Vol 55, Issue 4 > > Send ipv6-wg mailing list submissions to > ipv6-wg(a)ripe.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.ripe.net/mailman/listinfo/ipv6-wg > or, via email, send a message with subject or body 'help' to > ipv6-wg-request(a)ripe.net > > You can reach the person managing the list at > ipv6-wg-owner(a)ripe.net > > When replying, please edit your Subject line so it is more specific than "Re: Contents of ipv6-wg digest..." > > > Today's Topics: > > 1. Re: ipv6-wg Digest, Vol 55, Issue 2 (Benedikt Stockebrand) > 2. Re: ipv6-wg Digest, Vol 55, Issue 2 (Silvia Hagen) > 3. Re: ipv6-wg Digest, Vol 55, Issue 2 (Sander Steffann) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 25 Apr 2016 18:13:35 +0000 > From: Benedikt Stockebrand <bs(a)stepladder-it.com> > To: christian bretterhofer <christian.bretterhofer(a)gmail.com> > Cc: ipv6-wg(a)ripe.net > Subject: Re: [ipv6-wg] ipv6-wg Digest, Vol 55, Issue 2 > Message-ID: <87eg9th7zk.fsf(a)moa.stepladder-it.com> > Content-Type: text/plain > > Hi Christian and list, > > christian bretterhofer <christian.bretterhofer(a)gmail.com> writes: > >> I think the basic work for ISPs in concern to IPv6 is covered. > > well, depends on the ISP in question. To me it looks a lot like many are still struggling to get the necessary knowledge and experience to their tech and support crowd---not necessarily with the people actively involved in the RIPE community, but at least with the big ones. > > A customer recently asked one of the large players here in Germany if they were interested in a contract that would have allowed my customer to outsource some IPv6-related tasks---or rather, to outsource some tasks that were also expected to be supported via IPv6. They were turned down with the explanation "we don't have the necessary manpower to operate this". > >> But i miss the topics to be addressed if you want to migrate from a >> IPv4 Microsoft Active domain using company to an system where most >> server in an enterprise could by just IPv6 only and use technologies >> like NAT46 ( SIIT-DC ) or similar to still make IPv4 only windows >> clients happy. > > Now I've taken a bit of a look at these things, but then I'm not exactly a Microsoft guy. From all I've seen, going for NAT64 and such is generally a bad idea. Instead, ensure that IPv6 is provided wherever it is needed and then make your servers dual stacked. > > Yes, that frequently involves upgrades on various servers nobody really wants to touch, but the very reasons why nobody wants to touch them are the reasons why you actually clean that stuff up. > >> Switching an enterprise with location around the global from a "we >> donot route any IPv6 traffic across our WAN Links" "most servers have >> IPv6 disabled" to >> We start IPv6 routing partially and enable partial IPv6 support on >> servers in a Microsoft ADS environment seems not covered in most IPv6 >> covering websites and presentations. > > That may be because your approach is unnecessarily painful. You want to get IPv6 up and running in the network infrastructure first, then make your servers dual-stacked and then deal with the clients. > > At least that's the "strategic" outline of an approach. Beyond that it's really a lot of detail work to do on an individual basis. > >> Maintaining dual stack for the datacenters is just painfull and there >> should be a "single" device in the form of NAT46/SIIT/SIIT-DC in front >> of each server area. I am not sure that Active directory is ready for >> that. > > Nonononono, don't do that. Whenever something goes wrong with that "single device", you'll have a serious disruption of service, not everything works through it, and you'll never ever get a chance to get rid of it in the long run because there'll always be that one last server that depends on it, or might depend on it but nobody knows for sure. > > Yes, that means that you need to have all your servers dual stacked, and yes, that's some serious extra workload in a data center context, but anything else is quite likely way worse. > > > 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/ > > > > ------------------------------ > > Message: 2 > Date: Mon, 25 Apr 2016 18:35:28 +0000 > From: Silvia Hagen <silvia.hagen(a)sunny.ch> > To: Benedikt Stockebrand <bs(a)stepladder-it.com>, christian > bretterhofer <christian.bretterhofer(a)gmail.com> > Cc: "ipv6-wg(a)ripe.net" <ipv6-wg(a)ripe.net> > Subject: Re: [ipv6-wg] ipv6-wg Digest, Vol 55, Issue 2 > Message-ID: <F1D4404E5E6C614EB9D3083F4D15A7E70129FFFA@hex02> > Content-Type: text/plain; charset="iso-8859-1" > > That would be a great panel discussion with some diverse speakers on the panel :-) > > Silvia > > -----Urspr?ngliche Nachricht----- > Von: ipv6-wg [mailto:ipv6-wg-bounces@ripe.net] Im Auftrag von Benedikt Stockebrand > Gesendet: Montag, 25. April 2016 20:14 > An: christian bretterhofer > Cc: ipv6-wg(a)ripe.net > Betreff: Re: [ipv6-wg] ipv6-wg Digest, Vol 55, Issue 2 > > Hi Christian and list, > > christian bretterhofer <christian.bretterhofer(a)gmail.com> writes: > >> I think the basic work for ISPs in concern to IPv6 is covered. > > well, depends on the ISP in question. To me it looks a lot like many are still struggling to get the necessary knowledge and experience to their tech and support crowd---not necessarily with the people actively involved in the RIPE community, but at least with the big ones. > > A customer recently asked one of the large players here in Germany if they were interested in a contract that would have allowed my customer to outsource some IPv6-related tasks---or rather, to outsource some tasks that were also expected to be supported via IPv6. They were turned down with the explanation "we don't have the necessary manpower to operate this". > >> But i miss the topics to be addressed if you want to migrate from a >> IPv4 Microsoft Active domain using company to an system where most >> server in an enterprise could by just IPv6 only and use technologies >> like NAT46 ( SIIT-DC ) or similar to still make IPv4 only windows >> clients happy. > > Now I've taken a bit of a look at these things, but then I'm not exactly a Microsoft guy. From all I've seen, going for NAT64 and such is generally a bad idea. Instead, ensure that IPv6 is provided wherever it is needed and then make your servers dual stacked. > > Yes, that frequently involves upgrades on various servers nobody really wants to touch, but the very reasons why nobody wants to touch them are the reasons why you actually clean that stuff up. > >> Switching an enterprise with location around the global from a "we >> donot route any IPv6 traffic across our WAN Links" "most servers have >> IPv6 disabled" to >> We start IPv6 routing partially and enable partial IPv6 support on >> servers in a Microsoft ADS environment seems not covered in most IPv6 >> covering websites and presentations. > > That may be because your approach is unnecessarily painful. You want to get IPv6 up and running in the network infrastructure first, then make your servers dual-stacked and then deal with the clients. > > At least that's the "strategic" outline of an approach. Beyond that it's really a lot of detail work to do on an individual basis. > >> Maintaining dual stack for the datacenters is just painfull and there >> should be a "single" device in the form of NAT46/SIIT/SIIT-DC in front >> of each server area. I am not sure that Active directory is ready for >> that. > > Nonononono, don't do that. Whenever something goes wrong with that "single device", you'll have a serious disruption of service, not everything works through it, and you'll never ever get a chance to get rid of it in the long run because there'll always be that one last server that depends on it, or might depend on it but nobody knows for sure. > > Yes, that means that you need to have all your servers dual stacked, and yes, that's some serious extra workload in a data center context, but anything else is quite likely way worse. > > > 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/ > > > > > ------------------------------ > > Message: 3 > Date: Mon, 25 Apr 2016 19:45:27 +0100 > From: Sander Steffann <sander(a)steffann.nl> > To: Silvia Hagen <silvia.hagen(a)sunny.ch> > Cc: christian bretterhofer <christian.bretterhofer(a)gmail.com>, > "ipv6-wg(a)ripe.net" <ipv6-wg(a)ripe.net> > Subject: Re: [ipv6-wg] ipv6-wg Digest, Vol 55, Issue 2 > Message-ID: <0831019F-B2A2-40DB-99E4-9CAA526D1581(a)steffann.nl> > Content-Type: text/plain; charset="iso-8859-1" > > Hi, > >> Op 25 apr. 2016, om 19:35 heeft Silvia Hagen <silvia.hagen(a)sunny.ch> het volgende geschreven: >> >> That would be a great panel discussion with some diverse speakers on >> the panel :-) > > I have been doing some enterprise stuff as well recently. If there is going to be such a panel I would love to participate! :) > > Cheers, > Sander > >

2 1

what is v6-only?
by Bajpai, Vaibhav 05 May '16

05 May '16

Hello, What does v6-only mean? a) A client only has v6 address and can only route to v6 destinations b) A client only has v6 address but can route to dual-stack destinations using a network translator (such as NAT64) IIRC, IETF SSIDs are named: 'v6 only + nat64’. Personally when someone says v6-only I presume a), but lately I have seen people say v6-only although they mean b). PS: Sorry for a silly question Best, Vaibhav =================================== Vaibhav Bajpai www.vaibhavbajpai.com Room 91, Research I School of Engineering and Sciences Jacobs University Bremen, Germany ===================================

5 4

IPv6 WG Agenda
by Jen Linkova 03 May '16

03 May '16

Hi IPv6-Enthusiasts ;) I'm sure most of you have noticed that already, but the agenda for IPv6 WG sessions @ RIPE72 has been published: https://ripe72.ripe.net/programme/meeting-plan/ipv6-wg/ See you in Copenhagen soon! -- SY, Jen Linkova aka Furry on behalf of IPv6 WG Chairs

1 0

RIPE72 IPv6 WG: call for presentations
by Jen Linkova 20 Apr '16

20 Apr '16

Dear IPv6 Enthusiasts ;) I know that 23 of May 2016 when RIPE72 will start looks so away but we (IPv6 WG Chairs) like to plan ahead! If you would like to present at IPv6 WG session or just have any suggestions on the agenda (what we should or should not be talking about) - please email ipv6-wg-chairs(a)ripe.net >From presenters 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). For the last few meetings we filled all the agenda slots quite earlier and unfortunately had to reject a number of interesting talks because they were submitted too late. So don't be shy! If you *might* be able to present but not sure yet - also let us know. -- SY, Jen Linkova aka Furry on behalf of IPv6 WG Chairs.

3 2

New on RIPE Labs: 10,000 LIRs with IPv6 Resources
by Mirjam Kuehne 29 Feb '16

29 Feb '16

Dear colleagues, This week, we saw the 10,000th Local Internet Registry (LIR) received IPv6 addresses. The first block of IPv6 addresses was allocated from IANA to the RIPE NCC in 1999, so we have been distributing IPv6 addresses for 17 years. In this new article on RIPE Labs we track the policy developments that have made it progressively easier for LIRs to get the IPv6 they need: https://labs.ripe.net/Members/nathalie_nathalie/10-000-lirs-with-ipv6-resou… Kind regards, Mirjam Kuehne RIPE NCC

2 1