- ipv6-wg - mailman.ripe.net

Re: [ipv6-wg] Have we failed as IPv6 Working Group?
by Lee Howard 05 Oct '19

05 Oct '19

On 10/5/19 12:06 PM, Dave Taht wrote: > Lee Howard <lee(a)asgard.org> writes: > > >> IPv6 deployment in your network means cutting your NAT expense in >> half. More, as more sites deploy. > There's no fungable or measureable "NAT expense". NAT generally saves > money. Look at the container market for one recent example. If you have a dedicated box or service card for NAT, you have a specific NAT expense. If you can buy a smaller box for half the cost, you've saved a specific amount of money. I know of mobile carriers who NATted every Internet connection in IPv4, and have halved their capital expense on NAT. >> IPv6 deployment in your network might mean you can sell some of your >> IPv4 addresses, a clever way I've seen to fund the transition. > That I agree with. But I see no sign anyone is actually doing that. It's > saner to horde at the moment. I've had inquiries along these lines, and written proposals. >> IPv6 deployment on your web site means improving your page load time, >> and therefore SEO, and therefore revenue. At NANOG I showed quotes >> that IPv6 increases revenue by 0.2%-7%.[1] > BS. Happy eyeballs costs time. Here's my assessment: https://www.retevia.net/why-is-ipv6-faster/ >> The cost to deploy IPv6 is not high: it's mostly labor, and people who > BS. It needs to be implemented first in a deployable state. "Deployable"? It's been deployed by the millions. Everyone who's done it says it was mostly labor. >> complain that there's no training are ignoring the hundreds of >> tutorials, books, articles, videos, and web sites available to them >> for free, not to mention the thousands of friendly engineers. >> >> To everyone who sees a high cost, I ask whether you know the value of >> NAT reduction and web site speed (and avoiding buying addresses, or > I note that port exaustion is a real thing on ipv4 networks today that > more should measure. In one recent set of "coffee shop tests", I had an > over 30% initial syn failure rate. I don't know why (we were also > testing ecn) at the moment, but that was a shocking number. > > ipv4 dns with udp was already using up a lot of udp port space. > with quic eating up a lot of udp more, I'm not happy. > > JUST deploying dns over IPv6 as I did Interesting! > >> selling addresses), in $LOCAL_CURRENCY, so you can evaluate every >> obstacle you might encounter. For instance, "Our web conferencing >> doesn't support IPv6, and it'll cost us $9,000 a year to change. But >> IPv6 will save us $30,000." The decision is easy. > That last number is pure BS. It's not a single cost. It's that last > dangling set of apps that can't be converted to ipv6 that's the infinite > cost. I'm not sure what you're calling "BS." Obviously $30,000 was a made-up number for the example. I don't know what "dangling set of apps" you mean that can't be converted, especially in the context of "How much would it cost to add IPv6 support?" >> In another message on this thread I noted that small ISPs are squeezed >> between CPE and IPv4 purchases. They can't get CPE that supports IPv6, >> or that supports MAP or 464xlat, because they don't buy enough, so >> they have to pay to buy addresses. > They can't get cheap CPE that has those features. ALL that code runs > great in openwrt. > > And ipv4 addresses are needed until ipv6 hits 100% deployment. Fewer IPv4 addresses are needed in the context of MAP or 464xlat. >> That's easily solved by collective >> action: 100 small ISPs can get the features they want (at a better >> discount) than one acting alone. > Great. Is there an ISP association trying to do that already? Not that I know of. If there's interest, I'll support, maybe organize. Lee

1 0

Re: [ipv6-wg] Have we failed as IPv6 Working Group?
by Lee Howard 05 Oct '19

05 Oct '19

On 10/5/19 11:53 AM, Dave Taht wrote: > Lee Howard <lee(a)asgard.org> writes: > >> On 10/4/19 4:55 PM, Dave Taht wrote: >>> not being able to get a >>> static IPv6 address out of comcast, my hurricane tunnel getting blocked >>> by netflix, the still-huge prefix sub-distribution problem. The idea of >>> dynamic 2 week prefixes in part of the world prone to earthquakes >>> doesn't work for me... >> I can think of several programmatic ways to deal with that. > ... > > for real use a static ipv6/48 to distribute is needed. Dynamic ipv6 > assignments are fine if you are doing trivial stuff but if ipv6 is ever > to even start to supplant ipv4 it's got to become more static. Or more resilient to renumbering. I didn't mean to suggest that you as a user should have to code your home network. I meant that we (maybe IETF) have not done well at handling the case of "I received a new prefix, and I am the edge router; I need to tell everything else what changed." Thus kicking off RAs, DHCPv6 updates, dDNS updates, and a firewall that understands dynamic prefixing. >> I was thinking about some Hackathon projects to add IPv6 capability to >> open source projects. Seems to me the hardest part is making sure >> there's an adequate test environment. > Hackathons ARE useful tools for getting a short burst of focused work > out of people sharing the same space and time, but too many are thinking > hackathons alone will solve more detailed design, coding and iteration > problems; it's one of those ideas trivializing the costs of "Real > Programming(tm)" that really bugs me nowadays. > > I could share here the detailed project management stuff that went into > cerowrt's run (3 years), or the outline of work we did for > make-wifi-fast - which we've now been at for over 5 years now - 3+ to > get fq_codel to work right on wifi, 2 to rework the API to work for more > devices, and a pointer to the latest work which has been going for 3+ > months now - and for all that we've only accomplished about 1/10th what > we wanted to do, and only on 4 chipsets (most recently intel's ax200 > chips) out of the hundreds. This might make for an interesting WG discussion, getting actual work organized and done. >>>>> But Mr.Rey's reference about IPv6 deployment rates also makes a good point! >>>> Nobody cares about deployment rates. What good does it do, if people don't use it ? >>>> This is more realistic : https://www.google.com/intl/en/ipv6/statistics.html >>>> During the week, we are below 25%. >> (Replying to an item upthread) >> >> APNIC's statistics show that in almost every network that has IPv6, it >> is almost always used. > I pointed to coffee shops as one counter example. If they don't have IPv6, they're not using it. > To the lack of > DHCPv6-PD on android (and I think, IOS) for tethering as another. Based on discussions at IETF, I guess Android is expecting to get multiple IPv6 addresses and reassign as needed. Don't know about IOS. >> Another thought I've had: >> >> One of the reasons small ISPs can't deploy IPv6 is that they don't >> control the features in the CPE, because they don't buy enough. >> >> I know a couple CPE vendors who would be happy to provide a specific >> feature set for a guaranteed purchase of a couple thousand units a >> month. This sounds like a good business to me: if a bunch of small >> ISPs each contract for a specific number of units, but require >> RIPE-554, RFC7084, and RFC8085, we could both get the needed features, >> and get a larger volume discount than they get now. > Yes, the smaller ISPs should join together in a buying > club like that. Tried to get that going in NZ once. Failed. > > tried harder to make the aftermarket do the right thing - the eeros and > google wifi's of the world are doing ok, the bottom part of the market > just copy/pastes whatever's in openwrt at that moment, slaps a label > on it and ships it. So we focused on making the openwrt base as good > as possible. Might be another part of "What the WG should do" discussion. >> Saving $1 per CPE is better than spending $20 for an IPv4 address for >> every new user. Please confirm my math. :) > I always thought that ISPs would invest in their CPE far more than they > have. Free.fr being a shining example! ISPs get paid for modem rentals > and have customer support costs that could be reduced - that should have > been a great ongoing funding source and motivation, alone. > > but I know a few vendors, like evenroute, doing bufferbloat AND ipv6 > right, that have totally failed to crack ISP market thus far. > > and for no reason I can think of, the rental folk don't push out > new hardware OR new software to their users - I think charter made > an effort to get docsis 3.1 stuff out there and retire all the docsis > 2.0 gear in place, but not comcast. > > Secondly none of those ipv6 standards help when you still really need a > real IPv4 address, so yer still out the $20, IF you can buy the /24s you > need. And there's more ipv6 RFCs left without running, integrated code, > to support them. In my experience, accountants run the CPE purchasing, and saving 5¢ per unit is worth more to them than avoiding 10% of them driving $30 support calls. Same with rentals: why replace when the cost is already completely written off? There are some good reasons (like technical debt dragging on forward competitiveness) to replace. It may be the case that not everyone needs a unique IPv4 address. Several broadband ISPs have deployed DS-Lite, for example. I don't know the business model; do they charge for unique IPv4 addresses when needed? That's sort of back to my other point of aligning expenses and revenues. >> You just mentioned your un-upgradable "OS/2 Warp, MS-DOS, Windows 95, >> HPUX, Solaris, Windows 2000," and now you say it's easy to upgrade. > I didn't say it was "easy to upgrade" in the context of this legacy > gear, I said it was easy to "add" 420m addresses. 240/4 is almost fully > enabled in every OS except windows, for example. Fixed the last bug > in it for linux and openwrt last december. Deploying. 0/8 now. What's the relative level of support for unicast 240/4 and IPv6? > > Yea, people keep missing on this point. IPv6 is not globally reachable > either. To try and clarify: A new IOT device trying to backhaul its > data to 240.0.0.1 doesn't need to have a windows OS also trying to get to > that same address. Is that clearer? A new application can try to use > new IPv4 addresses. Do you mean 240/4 for private connectivity, or 240/4 publicly routed and it's fine for some applications if it's unreachable? Do all routers etc support it? Lee

1 0

Disband IPv6 WG
by Blake 05 Oct '19

05 Oct '19

As the OP's goal seems to be XKCD standards compliance(1), perhaps it's time to revive IPv10? https://tools.ietf.org/html/draft-omar-ipv10-11 After all, it took Edison two decades to admit DC power distribution couldn't work, & NYC only had to wait a century more until they could decommission their commercial DC electrical power distribution network... ( https://en.wikipedia.org/wiki/War_of_the_currents ) -Blake 1) https://xkcd.com/927/

2 1

Re: [ipv6-wg] IPv6 WG co-chair selection
by Erik Bais 03 Oct '19

03 Oct '19

Hi Raymond, You have my support for another round. Erik Bais From: ipv6-wg <ipv6-wg-bounces(a)ripe.net> on behalf of "raymond.jetten(a)elisa.fi" <raymond.jetten(a)elisa.fi> Date: Friday 13 September 2019 at 12:04 To: RIPE IPv6 WG <ipv6-wg(a)ripe.net> Cc: "ipv6-wg-chairs(a)ripe.net" <ipv6-wg-chairs(a)ripe.net> Subject: [ipv6-wg] IPv6 WG co-chair selection Hello again, Apologies for the previously incomplete and spelling mistakes email. I hope below is a better version : -- Hello All, Its almost 3 years ago that I started as a IPv6-WG co-chair, so as per our current policy it's time to step down. However, I’m very willing to stand for re-selection, and serve another term as IPv6 WG co-chair, which I hope you all find a good idea. The full process is described here: https://www.ripe.net/participate/ripe/wg/ipv6/ipv6-wg-chair-selection-proce… See you all in Rotterdam! Rgds, Ray

2 1

Re: [ipv6-wg] Disband IPv6 WG
by Jens Link 03 Oct '19

03 Oct '19

Uros Gaber <uros(a)gaber.in> writes: > On 3 Oct 2019, at 14:03, Job Snijders <job(a)instituut.net> wrote: >> Even worse, delivering email over ipv6 to the mail giants is a far >> worse experience than via ipv4. More emails arrive when you >> disable ipv6 on your mail servers. > I would say the same experience as long as the server and supported > services are configured correctly. If you google correctly you'll find many people compiling about google not accepting mail via IPv6. Therefore not many people do SMTP via IPv6. Or if they do they have an extra (v4 only) transport in their outgoing SMTP server. ==> Runing Dualstack is more work. Jens -- ---------------------------------------------------------------------------- | Delbrueckstr. 41 | 12051 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink(a)quux.de | --------------- | ----------------------------------------------------------------------------

1 0

Re: [ipv6-wg] IPv6 WG co-chair selection
by Paul Hoogsteder 03 Oct '19

03 Oct '19

Hello Routing WG members, I support Raymond's re-election. Kind regards, Paul Hoogsteder Meanie AS31019

1 0

Re: [ipv6-wg] IPv6 WG co-chair selection
by Kennedy, James 02 Oct '19

02 Oct '19

+1 support for Ray Regards, James From: ipv6-wg [mailto:ipv6-wg-bounces@ripe.net] On Behalf Of Jetten Raymond Sent: 13 September 2019 12:04 To: RIPE IPv6 WG <ipv6-wg(a)ripe.net> Cc: ipv6-wg-chairs(a)ripe.net Subject: [ipv6-wg] IPv6 WG co-chair selection Hello again, Apologies for the previously incomplete and spelling mistakes email. I hope below is a better version : -- Hello All, Its almost 3 years ago that I started as a IPv6-WG co-chair, so as per our current policy it's time to step down. However, I'm very willing to stand for re-selection, and serve another term as IPv6 WG co-chair, which I hope you all find a good idea. The full process is described here: https://www.ripe.net/participate/ripe/wg/ipv6/ipv6-wg-chair-selection-proce… See you all in Rotterdam! Rgds, Ray

1 0

IPv6 WG co-chair selection
by Jetten Raymond 01 Oct '19

01 Oct '19

Hello again, Apologies for the previously incomplete and spelling mistakes email. I hope below is a better version : -- Hello All, Its almost 3 years ago that I started as a IPv6-WG co-chair, so as per our current policy it's time to step down. However, I'm very willing to stand for re-selection, and serve another term as IPv6 WG co-chair, which I hope you all find a good idea. The full process is described here: https://www.ripe.net/participate/ripe/wg/ipv6/ipv6-wg-chair-selection-proce… See you all in Rotterdam! Rgds, Ray

6 5

IPv6 WG agenda
by Jen Linkova 01 Oct '19

01 Oct '19

Hello, The agenda for IPv6 WG session at RIPE79 has been published: https://ripe79.ripe.net/programme/meeting-plan/ipv6-wg/ See you all in Rotterdam! -- SY, Jen Linkova aka Furry on behalf of IPv6 WG chairs.

1 0

IPv6 WG chair election
by Jetten Raymond 19 Sep '19

19 Sep '19

Hello All, Its almost 3 years ago that I started as a IPv6-WG co-chair, so as per our current policy it's time to step down. However, I'm very willing to stand for re-election, and serve another term as IPv6 WG co-chair, which I hope you all find a good idea. See you all in Rotterdam! Rgds, Ray

14 13

Re: [ipv6-wg] IPv6 WG co-chair selection
by Janos Zsako 18 Sep '19

18 Sep '19

Dear Ray, > Its almost 3 years ago that I started as a IPv6-WG co-chair, I think you did a very good job, thank you. > so as per our current policy it's time to step down. > > However, I'm very willing to stand for re-selection, and serve another term as IPv6 WG co-chair, which I hope you all find a good idea. I am glad to hear this. I strongly support your re-election. Best regards, Janos > Rgds, > Ray

1 0

RIPE 78 Minutes
by Jetten Raymond 14 Sep '19

14 Sep '19

Hello all, The minutes from RIPE 78 are now available: https://www.ripe.net/participate/ripe/wg/ipv6/minutes/ipv6-working-group-mi… Please let us know if you have any comments. Cheers, Jen, Benedikt and Ray

1 0

RIPE 79 IPv6 Working group
by Jetten Raymond 30 Jul '19

30 Jul '19

Hello All, The RIPE 79 meeting will take place will take place in Rotterdam Netherlands from 14-18 October 2019. https://ripe79.ripe.net/ The IPv6 WG session will most likely be on Thursday Morning. (still subject to change). Would you like to present at our WG session, and have a subject that would be of interest on IPv6, or develop IPv6 related RIPE policies, have useful recommendations, or plan other documents that will help the deployment of 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 Rotterdam, Jen, Benedikt, Ray

1 0

IPv6 SLAAC renum/problems IETF I-D (Fwd: New Version Notification for draft-gont-v6ops-slaac-renum-00.txt)
by Fernando Gont 07 Jul '19

07 Jul '19

Folks, To make the story short: Based on the recent discussion we had on our IETF I-D draft-gont-6man-slaac-renum, we have posted this new I-D which focuses on discussing the problem, and describing operational mitigations. The document is available at: https://www.ietf.org/internet-drafts/draft-gont-v6ops-slaac-renum-00.txt Comments are welcome. It is being discussed on the IETF v6ops wg mailing-list: https://mailarchive.ietf.org/arch/msg/v6ops/5D2hdpB6QHRm9u-MUj6erQaLZY0 If possible, post your comments on the v6ops wg list. But comments are welcome, whether there, here, or even unicast to us (co-authors) ;-) Thanks! Cheers, Fernando -------- Forwarded Message -------- Subject: New Version Notification for draft-gont-v6ops-slaac-renum-00.txt Date: Sat, 06 Jul 2019 08:59:12 -0700 From: internet-drafts(a)ietf.org To: Fernando Gont <fgont(a)si6networks.com>, Jan Zorz <jan(a)go6.si>, Richard Patterson <richard.patterson(a)sky.uk> A new version of I-D, draft-gont-v6ops-slaac-renum-00.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Name: draft-gont-v6ops-slaac-renum Revision: 00 Title: Reaction of Stateless Address Autoconfiguration (SLAAC) to Renumbering Events Document date: 2019-07-06 Group: Individual Submission Pages: 14 URL: https://www.ietf.org/internet-drafts/draft-gont-v6ops-slaac-renum-00.txt Status: https://datatracker.ietf.org/doc/draft-gont-v6ops-slaac-renum/ Htmlized: https://tools.ietf.org/html/draft-gont-v6ops-slaac-renum-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-gont-v6ops-slaac-renum Abstract: In scenarios where network configuration information related to IPv6 prefixes becomes invalid without any explicit signaling of that condition (such as when a CPE crashes and reboots without knowledge of the previously-employed prefixes), nodes on the local network will continue using stale prefixes for an unacceptably long period of time, thus resulting in connectivity problems. This document analyzes these problem scenarios, and discusses operational workarounds to improve network robustness. 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

IPv6 faster than IPv4 (also with 464XLAT)
by JORDI PALET MARTINEZ 26 Jun '19

26 Jun '19

We already knew that from previous measurements, however the nice thing from this article is that it is analyzing many different providers worldwide: https://teamarin.net/2019/06/25/why-is-ipv6-faster/ Regards, Jordi @jordipalet ********************************************** 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

RIPE NCC Receives Additional /12 IPv6 Allocation from IANA
by Nikolas Pediaditis 07 Jun '19

07 Jun '19

Dear colleagues, On 5 June 2019, the RIPE NCC received the following IPv6 allocation from IANA: 2a10:0000::/12 All allocations of IPv6 unicast address space made by IANA to RIRs are listed here: https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unic… We received our previous /12 allocation (2a00:0000::/12) on 3 October 2006. The conditions under which we qualified for an additional allocation are described in the IANA Policy For Allocation of IPv6 Blocks to RIRs: https://www.icann.org/resources/pages/allocation-ipv6-rirs-2012-02-25-en The RIPE NCC is the first RIR to receive an additional /12 IPv6 block. As today is also the seventh anniversary of World IPv6 Launch Day, we took the opportunity to look at some of the history of IPv6 and how it has been distributed in our service region: https://labs.ripe.net/Members/riccardo_stagni/we-re-running-out-of-ipv6 Kind regards, Nikolas Pediaditis Registration Services & Policy Development Assistant Manager RIPE NCC

6 6

Useful Information / RIPE78
by Thomas Schäfer 17 May '19

17 May '19

Hi, Is it right, that I can use https://ripe78.ripe.net/on-site/tech-info/ipv6-only-network/ or https://ripe78.ripe.net/on-site/tech-info/dns-over-tls-resolvers/ but not both at the same time? Regards, Thomas -- There’s no place like ::1 Thomas Schäfer (Systemverwaltung) Ludwig-Maximilians-Universität Centrum für Informations- und Sprachverarbeitung Oettingenstraße 67 Raum C109 80538 München ☎ +49/89/2180-9706 ℻ +49/89/2180-9701

3 4

IPv6 WG Ripe 77 meeting minutes, your comments please
by Jetten Raymond 07 May '19

07 May '19

Hello All, Here are the minutes form the previous meeting in Amsterdam, if you have any comments on the content of them, please contact us ( ipv6-wg-chairs(a)ripe.net<mailto:ipv6-wg-chairs@ripe.net> ) In a little over 2 weeks we will approve the minutes including the comments at the RIPE78 meeting in Reykjavik. IPv6 Working Group Minutes - RIPE 77 Date: 18 October 2018, 11:00 - 12:30 WG Co-Chairs: Jen Linkova, Benedikt Stockebrand, Raymond Jetten  Scribe: Massimiliano Stucchi   Status: Draft 1. Welcome/Agenda Bashing/Meeting Minutes The presentation is available at https://ripe77.ripe.net/archives/video/2278/ There were no questions or comments. 2. IPv6 Work at IETF (v6ops/6man WGs updated) Jen Linkova, WG Co-Chair The presentation is available at: https://ripe77.ripe.net/archives/video/2279/ Pawel Lunin from Scaleway mentioned that RFC8475 was recently published, and asked for a more detailed explanation from Jen Linkova, one of the authors. Marco Hogewoning from RIPE NCC thanked the presenters and asked to point those interested towards smaller Internet drafts that haven't been adopted by Working Groups. He suggested taking a look at a specific draft on ENUM numbers and said that participants in the room should comment on that. Cyril Malevanov from Selectel spoke against IPv6 on behalf of the operators from St. Petersburg. He said he wanted his voice to be heard, and to state his opinion. Alissa Cooper, IETF Chair, thanked the presenters on behalf of the IETF. She also stated that if there were ideas, people could approach her and other IETF participants to get help. There were no more questions or comments. 3. Clusters in the Expanse: Understanding and Unbiasing IPv6 Hitlists Oliver Gasser, RACI The presentation is available at: https://ripe77.ripe.net/archives/video/2283/ Jen Linkova, Google, said she liked the conclusions because she finds it hard to understand the issue of security by obscurity. The presenter answered that there was a previous paper that compared the reachability of IPv4 against IPv6 and the outcome was that IPv6 addresses are more likely to respond because firewall rules were not set. Randy Bush, IIJ and Archis asked about the IPv6 responsiveness graph in the slides and how it compares to IPv4. The presenter answered that the numbers are in the paper, but couldn't provide any more data as he couldn't remember it in detail. There were no more questions or comments. 4. We Don't Need IPv6 - Update Jens Link The presentation is available at: https://ripe77.ripe.net/archives/video/2285/ Jen Linkova, Google, commented during the presentation that she wouldlike to do the"IPv6 bullshit bingo" if any more references to a paper mentioned during thepresentation will be highlighted. Randy Bush, IIJ, mentioned that they tried turning off IPv4 at the lastIETF,specifically for the IPv6-related Working Groups (6man, v6ops) and it didn'twork out the way they would have liked. They tried NAT64. Hesaid unfortunately there is still work to be done. Jen Linkova said there were bugs in the network, and 75% of the peoplereported they had no problems getting work done in a survey sent later. There were no more questions nor comments. 5. The Art of Running Out of IPv6 Addresses Benedikt Stockebrand The presentation is available at: https://ripe77.ripe.net/archives/video/2287/ Jan Zorz thanked the presenter and seconded the fact that history repeats itself over and over again, and errors keep being repeated. There were no more questions nor comments. --- The minutes are also available online: https://www.ripe.net/participate/ripe/wg/ipv6/minutes/ipv6-working-group-mi… Rgds, IPv6-WG-Chairs: Jen, Benedikt, Ray

1 0

Agenda for the IPv6 Working group at Ripe 78 Reykjavik
by Jetten Raymond 01 May '19

01 May '19

Dear All, We have published the agenda for the IPv6 working group at the Ripe 78 meeting in Reykjavik Iceland Thursday, 23 May 09:00 - 10:30 A. Welcome, Agenda Bashing [5 min] B. IPv6 Reliability Measurements [30 min] Geoff Huston C. Large-Scale Deployment of IPv6-Enabled Wi-Fi Hotspots [30 min] Enno Rey D. Update on ITU SG-20 IPv6 Deployment Plan [5 min] Marco Hogewoning E. Mobile IPv6 BCOP Doc [5 min] Massimiliano Stucchi F. RIPE-690 Follow-up: SLAAC’s Reaction to Renumbering Events - IETF I-D [15 min] Jan Zorz Thursday, 23 May 14:00 - 15:30 This session will be shared with the Routing Working Group Technology Deep Dive on Modern Router Architectures Ignas Bagdonas See you all in Reykjavik ! Rgds, IPv6 wg co-chairs: Jen, Benedikt and Ray

1 0

Update on ITU-T SG 20 activities: Ceased work on Y.IPv6RefModel
by Marco Hogewoning 18 Apr '19

18 Apr '19

Dear colleagues, At the meeting of ITU-T Study Group 20, in Geneva from 9-18 April, it was decided to end the work item to develop a "Reference model of IPv6 subnet addressing plan for Internet of things deployment" (Y.IPv6RefModel). We again would like to thank this working group for its contribution - both in reviewing the draft recommendation and sharing your concern about the technical merits of the proposed model. We would also like to thank our colleagues from ARIN, GSMA, the administrations of the United Kingdom, United States, Canada and Germany, and the Rapporteur and Associate Rapporteur of Question 3/20 for their contributions, advice and ongoing support in resolving this matter. The RIPE NCC of course, remains committed to promoting and supporting the deployment of IPv6, also with regards to those elements of the Internet of Things that deploy the Internet protocol. We hope to provide a more comprehensive report during this working group’s meeting at RIPE 78 in Reykjavik. Greetings from Geneva, Marco Hogewoning Senior External Relations Officer RIPE NCC

2 1

IPv6 Security for IPv4 Engineers
by Fernando Gont 14 Mar '19

14 Mar '19

Folks, It is often argued that IPv4 practices should be forgotten when deploying IPv6, as after all IPv6 is a different protocol! But we think years of IPv4 operational experience should be leveraged as much as possible. So we are publishing IPv6 Security for IPv4 Engineers as a roadmap to IPv6 security that is specifically aimed at IPv4 engineers and operators. Rather than describing IPv6 in an isolated manner, it aims to re-use as much of the existing IPv4 knowledge and experience as possible, by highlighting the security issues that affect both protocols in the same manner, and those that are new or different for the IPv6 protocol suite. Additionally, it discusses the security implications arising from the co-existence of the IPv6 and IPv4 protocols. The document is available at: https://www.internetsociety.org/blog/2019/03/ipv6-security-for-ipv4-enginee… Comments are welcome. And if you think we've missed something or the like, please drop me en email -- the document can always be revised. P.S.: If you haven't taken a look at it (yet), we have also published the "IPv6 Security Frequently Asked Questions (FAQ)" at: https://www.internetsociety.org/blog/2019/02/ipv6-security-faq 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 Implementation for an ISP
by Alessandro Valenza 13 Mar '19

13 Mar '19

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.

5 4

SSL VPN Clients
by christian bretterhofer 12 Mar '19

12 Mar '19

Sorry for a little be off topic query. I am checking which VPN solutions are IPv6 compatible outside and inside the tunnel and can so transport with any IPv6/IPv4 connection IPv6/IPv4 internal to then tunnel Maybe somebody made such tests already and can point me to it. What i found so far: Citrix SSL VPN ( seems to have only partial support) https://support.citrix.com/article/CTX233563 https://www.citrix.com/blogs/2010/07/13/are-citrix-products-ipv6-ready/ so IPv6 / IPv6 not yet supported https://support.citrix.com/article/CTX211780 NetScaler Gateway VPN users are not able to resolve IPv4 DNS when their ISP has IPv6 enabled. OpenVPN https://community.openvpn.net/openvpn/wiki/IPv6 No complete example found yet. Wireguard (LINUX only) seems to support it but missing other stuff like hostchecker Cisco SSL VPN https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_sslvpn/configura… IPv6 Support and Limitations for Pulse Connect Secure Features https://docs.pulsesecure.net/WebHelp/Content/PCS/PCS_AdminGuide_8.2/IPv6%20… Microsoft Direct access (win7/win10) and new Always on VPN (Win10 only) https://directaccess.richardhicks.com/2018/02/05/what-is-the-difference-bet… https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/vp… -- --- best regards Christian Bretterhofer

8 8

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