- ipv6-wg - mailman.ripe.net

Re: [ipv6-wg] IPv6 Implementation for an ISP
by JORDI PALET MARTINEZ 11 Mar '19

11 Mar '19

Hi Alessandro, I will suggest to for IPv6-only with IPv4-as-a-Service. I’m right now doing this deployment with 464XLAT for a customer this week, including wired and cellular access. You can find the slides of my last tutorial in the RIPE meeting at: https://ripe77.ripe.net/programme/meeting-plan/tutorials/ I guess there is a video as well, otherwise, I did a similar tutorial (even with hands-on in this case, total 3 hours) in the last APNIC (just two weeks ago) that you can search for. Regards, Jordi De: ipv6-wg <ipv6-wg-bounces(a)ripe.net> en nombre de Alessandro Valenza <a.valenza(a)enegan.it> Fecha: lunes, 11 de marzo de 2019, 17:41 Para: "ipv6-wg(a)ripe.net" <ipv6-wg(a)ripe.net> Asunto: [ipv6-wg] IPv6 Implementation for an ISP Hello, this is the first time I write in this mailing list. I have a question for you. I’m working for an ISP that obtained IPv4 (/22) and IPv6 (/29). I would like to use IPv6. Could you suggest me some documents and some manuals useful to implement IPv6, but avoiding problems for our customers? In particular, I would like to avoid compatibility problems with VoIP PBXs, network printers, alarm systems, etc ... In Italy only few ISPs provide IPv6 addresses and we would like to try to reverse this negative trend compared to the rest of Europe. I hope you can help me understanding the advantages and opportunities in investing in the direction of IPv6. Kind regards Alessandro Alessandro Valenza Ufficio TLC Tel: 0571 1738257 Fax: 0571542536 www.enegan.it CONFIDENZIALITÀ Questo messaggio, inclusi gli eventuali allegati, è indirizzato solo ai destinatari e può contenere informazioni riservate e confidenziali. Se avete ricevuto il messaggio senza esserne un destinatario, o un suo rappresentante autorizzato, la presente comunicazione vale come formale divieto di diffusione del contenuto del messaggio.Se avete ricevuto il messaggio per errore, siete pregati di cancellarlo, assieme a tutti gli allegati, dal vostro sistema e di informare immediatamente il mittente. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

1 0

SLAAC in renumbering events
by Fernando Gont 08 Mar '19

08 Mar '19

Folks, If you follow the 6man working group of the IETF you may have seen a bunch of emails on this topic, on a thread resulting from an IETF Internet-Draft we published with Jan Žorž about "Reaction of Stateless Address Autoconfiguration (SLAAC) to Renumbering Events" (Available at: https://github.com/fgont/draft-slaac-renum/raw/master/draft-gont-6man-slaac… ) Short version of story: There are a number of scenarios where SLAAC hosts may end up using stale configuration information. For example, a typical IPv6 deployment scenario is that in which a CPE router requests an IPv6 prefix to an ISP via DHCPv6-PD, and advertises a sub-prefix of of the leased prefix on the LAN-side, via SLAAC. In such scenarios, if the CPE router crashes and reboots, it may loose all information about the previously-leased prefix. Upon reboot, the CPE router may be leased a new prefix that will result in a new sub-prefix being advertised on the LAN-side of the CPE router. As a result, hosts will normally configure addresses for the newly-advertised prefix, but will normally also keep (and use) the previously-configured (and now stale!) IPv6 addresses, leading to interoperability problems. The RIPE-690 BCOP document had originally tried to address this problem by recommending operators to lease stable IPv6 prefixes to CPE routers. However, for a variety of reasons ISP may not be able (or may not want) to lease stable prefixes, and may instead lease dynamic prefixes. Most of the voices on the 6man wg mailing-list fell into one of the following camps: * "ISPs should be leasing stable prefixes -- if they don't, they are asking for trouble!" * "CPE routers should record leased prefixes on stable storage, such that they can 'deprecate' such prefixes upon restart -- if they don't, they are asking for trouble!" * "No matter whose fault is this (if there is any single party to blame in the first place), we should improve the robustness of IPv6 deployments" Our Internet-Draft tries to improve the current state of affairs via the following improvements: * Allow hosts to gracefully recover from stale network configuration information -- i.e., detect and discard stale network configuration information * Have SLAAC routers employ more appropriate timers, such that information is phased-out in a timelier manner -- unless it is actively refreshed by Router Advertisement messages * Specify the interaction between DHCPv6-PD and SLAAC -- which was rather under-specified * Require CPE routers to store leased prefixes on stable storage, and deprecate stale prefixes (if necessary) upon restart We are looking forward to more input on the document (or any comments on the issue being discussed), particularly from operators. So feel free to send your comments on/off list as you prefer Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont(a)si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

1 0

IPv6 Security Frequently Asked Questions (FAQ)
by Fernando Gont 08 Mar '19

08 Mar '19

Folks, The Internet Society has posted the "IPv6 Security Frequently Asked Questions (FAQ)" I authored. The document is available (HTML, and also easy-to-print PDF) at: https://www.internetsociety.org/deploy360/ipv6/security/faq/ If you think there are other questions that should be added, or have comments on the answers, please do let me know -- the document can eventually be revised. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont(a)si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

1 0

New on RIPE Labs: Deploying IPv6 at IBM
by Mirjam Kuehne 25 Feb '19

25 Feb '19

Dear colleagues, In this article, Andy Mindnich describes how IPv6 was introduced inside IBM’s own network over the past few years. As enterprises in general seem to lag behind in adopting IPv6 as compared to ISPs or carriers, this article is aimed at helping those who still need to build a case within their own company. https://labs.ripe.net/Members/andy_mindnich/deploying-ipv6-at-ibm Kind regards, Mirjam Kühne RIPE NCC

1 0

A common problem with SLAAC in "renumbering" scenarios
by Fernando Gont 31 Jan '19

31 Jan '19

Folks, We have posted a new I-D discussing a problem that can arise in typical deployment scenarios where the CPE obtains a prefix via DHCPv6-PD and advertises a prefix on the LAN side. We also propose a solution to the aforementioned problem. Our draft is available at: https://tools.ietf.org/html/draft-gont-6man-slaac-renum The Abstract is: A very common IPv6 deployment scenario is that in which a CPE employs DHCPv6 Prefix Delegation to obtain an IPv6 prefix, and at least one prefix from within the leased prefix is advertised on a local network via SLAAC. In scenarios where e.g. the CPE crashes and reboots, nodes on the local network continue using outdated prefixes which result in connectivity problems. This document analyzes this problem scenario, and proposes workarounds. Any comments will be welcome. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont(a)si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

1 0

IPv6 Working Group presentations for RIPE78
by Jetten Raymond 16 Jan '19

16 Jan '19

Hello All, The RIPE 78 meeting will take place will take place in Reykjavik Iceland from 20-24 May 2019. https://ripe78.ripe.net/ The IPv6 WG session will most likely be on Thursday after lunch. (still subject to change). Would you like to present at our WG session, and have a subject that would be of interest on IPv6? We, the IPv6 WG co-chairs, would like to invite you to submit your presentation proposals, including a brief description of the content and the time you would need. Please send them directly to us: ipv6-wg-chairs at ripe.net<https://lists.ripe.net/mailman/listinfo/ipv6-wg> . Once we start to make the final agenda, we will let you know if you are selected or not. Please be aware of the following: Due to potential technical issues, presenters/panelists should be physically present at the RIPE Meeting. RIPE Meeting attendees are quite sensitive to keeping presentations non-commercial, and product marketing talks are strongly discouraged. All sessions will be recorded and broadcasted, and will be publicly available afterwards, so make sure you own the copyrights of all content. See you in Reykjavik, Jen, Benedikt, Ray

1 0

New on RIPE Labs: Answering IPv6 Misconceptions
by Mirjam Kuehne 21 Dec '18

21 Dec '18

Dear colleagues, Please read these two new RIPE Labs articles by Jen Linkova where she responds to some common IPv6 misconceptions that are used as reasons for not deploying IPv6: https://labs.ripe.net/Members/jen_linkova/ipv6-misconceptions-it2019s-fake-… https://labs.ripe.net/Members/jen_linkova/ipv6-misconceptions-it2019s-fake-… Kind regards, Mirjam Kühne RIPE NCC

1 0

Report from ITU Study Group 20 meeting 3-13 December 2018 in Wuxi, China
by Marco Hogewoning 14 Dec '18

14 Dec '18

Dear colleagues, The meeting of ITU Study Group 20 in Wuxi, China, just finished and I’d like to give you a brief report on the discussions of the work on a draft Recommendation on IPv6 addressing. This meeting was the group's first face-to-face meeting since our discussion of the draft Recommendation at RIPE 77 in May 2018 and the July 2018 draft review deadline. The RIPE community's comments were brought to the meeting as a Liaison Statement. Several other parties also submitted their own Contributions, including the RIPE NCC in its role as an ITU Sector Member. The proposal in our Contribution, with reference to earlier discussions and your review, was to discontinue this particular Work Item. The United States Government and ARIN made Contributions along similar lines, seeking to stop the work developing this particular Recommendation. This position was also supported by the United Kingdom, Canada, Germany and several sector members. I’d like to highlight that both in their Contribution and interventions, the US expressed their gratitude to the RIPE community for their extensive review and feedback on the draft Recommendation. The main author of the draft submitted a Contribution with their account of our discussions at RIPE 77 and the review process, as well as a joint Contribution with the Beijing University for Post and Telecommunications providing a case study of an IPv6 address plan. Having taken all of these contributions and interventions into consideration, the focus of the meeting discussion was on whether or not the work should continue. Unfortunately, the RIPE community’s feedback was only taken into consideration as a high-level conclusion that the current text does not meet the technical standards expected, and the actual text of the draft was not reviewed or revised during this meeting. Unable to reach consensus, the question of whether the work should continue was deferred upwards to the meeting of the Working Party and finally to the closing plenary. During the closing plenary, the Chairman of Study Group 20 proposed continuing the work for at least one more meeting on the premise that the draft’s main author would come back with a Contribution addressing the concerns raised with the current draft. He emphasised that the work item would be dropped unless there were contributions and agreement to advance the text at the next meeting. The RIPE NCC accepted the Chairman’s proposal as a constructive way forward. We look forward to the contributions at the next meeting with the expectation that they will address the concerns raised during your review. We would like to thank you again for the constructive comments raised during the review process. We would also like thank the Question’s rapporteur, associate rapporteur and the Study Group’s management team for all their time and assistance, and of course all the member states and sector members that participated in this discussion. The next meeting of Study Group 20 is scheduled to take place in mid-April, in Geneva, Switzerland. Regards, Marco Hogewoning RIPE NCC

5 7

Re: [ipv6-wg] [cooperation-wg] Fwd: Report on ITU Study Group 20 meeting 3-13 December 2018
by Jim Reid 14 Dec '18

14 Dec '18

> On 14 Dec 2018, at 02:44, Marco Hogewoning <marcoh(a)ripe.net> wrote: > > Please find below a report on the meeting of ITU Study Group 20, that I have just shared with the IPv6 Working Group. Marco, as a fellow traveller on the SG20 bus, I thank you for this summary and all the hard work you did in Wuxi and in the preparations for that meeting. You did an excellent job and were a great ambassador for both RIPE and the NCC. You represented our interests very effectively. I appreciate that and hope everyone else here does too.

2 1

IPv6 transition mechanisms used around the world
by Yannis Nikolopoulos 30 Nov '18

30 Nov '18

Hello all, this probably hasn't been posted here so for everyone's info, there's a google spreadsheet created by IETF's Lee Howard, with information about transition mechanisms used by ISPs around the world. Obviously, anyone can edit and the more people add info, the more meaningful and useful it can become https://docs.google.com/spreadsheets/d/1ksOoWOaRdRyjZnjLSikHf4O5L1OUTNOO_7N… cheers, Yannis

1 0