- ipv6-wg - mailman.ripe.net

Can ripemtg SSID promotes NAT64 (at least) during RIPE80 ? :)
by Willy Manga 28 Feb '20

28 Feb '20

Hello, I was looking the trends of the last FOSDEM [1] and I recalled discussions before and during RIPE79. I humbly think you could give a try ... 1. https://blogs.cisco.com/getyourbuildon/fosdem-2020-trends-and-analysis -- Willy Manga @ongolaboy https://ongola.blogspot.com/

5 4

IPv6 WG Minutes - RIPE 79
by Jetten Raymond 16 Dec '19

16 Dec '19

Hello all, Please find attached the draft minutes from the IPv6 WG session at RIPE 79. Do let us know if you want any changes made to the minutes. If we haven't heard from you by 20 December, we'll assume all is in order and publish the minutes to the website as they are. Rgds, Ray, Jen, Benedikt For Internal Use Only

1 0

New on RIPE Labs: How to Build and Market IPv6-only Services
by Mirjam Kuehne 04 Dec '19

04 Dec '19

Dear colleagues, For those of you who missed Nico Schotteluis' presentation at RIPE 79, here is his story on how they built and marketed IPv6-only services (including cute penguin drawings :-)): https://labs.ripe.net/Members/nico_schottelius/how-to-build-and-market-ipv6… Kind regards, Mirjam Kühne RIPE NCC

1 0

Its that time of the year...
by Yannis Nikolopoulos 02 Dec '19

02 Dec '19

...when we're starting to deploy yet another IPv6-only technology :) Hello all, as a fairly large ISP (for Greek standards at least), we've been affected by IPv4 exhaustion for quite some time now. A few years back we gave LW4o6 a go, as documented here https://ripe76.ripe.net/presentations/11-lw4o6-deployment-as6799.pdf . In the end, it did not work out very well. Quoting myself (from v6ops mailing list), the reasons behind that were: "In no particular order: 1. CPE (almost OK after ~2 years and god knows how many iterations) 2. lwaftr performance (worth noting the the lwaftr is implemented as a VNF 3. vendor's reluctance to continue (much needed) dev/ment because of *lack of interest from other ISPs* " Please take extra note of (3). In any case, being the optimists we are, and having supportive mgmt, we decided (once more) against burying ourselves deeper into CGN. This time we're going with MAP-E (which incidentally was our first choice), mainly because we understand it and our MAP BR vendor does too :) . So, as I already mentioned, we're just about to deploy it commercially. We've tested with 2 CPE vendors sucessfully and we're just ironing out some provisioning details before launching. Deployment will be gradual of course and very very cautious. Unofficially, we are aware of a couple of similar trials from other ISPs and we'd love to hear about people who have already deployed such technologies (IPv6-only with IPv4aas) or are thinking about doing so. After all, that is exactly what this WG is about :) thanks for reading, Yannis

3 3

Re: [ipv6-wg] Its that time of the year...
by Jan Zorz - Go6 02 Dec '19

02 Dec '19

On 01/12/2019 20:57, Ole Troan wrote: >> No matter how hard you try, at the end of the day LW4o6 is still >> stateful mechanism. > > Just make sure there are no misunderstandings. MAP-E and LW46 both > have the same NAT placement (at the CPE). A MAP-E implementation can > implement LW46 by supporting a MAP rule per subscriber. So it’s more > correct to say that LW46 has per-user configured state, and that > MAP-E can aggregate this configured state into a few rules covering > the whole domain. Both are stateless, in contrast to a NAT that has > state per session. Ya, you are right. Got confused for a millisecond with dslight ;) Too many things going on right now. My bad. As far as I remember - LW4o6 is useful in cases where you don't have one huge IPv4 block of addresses to assign to the transition mechanism and/or where you want to dynamically assign additional ports to the CPE if it runs out of it. If none of this is a requirement, then MAP-E/T should be the way to go. Do we have any experiments/deployments of 464XLAT in fixed networks? CLAT in CPE and NAT64 in the core? Cheers, Jan

1 0

Disband IPv6 WG
by Jens Link 29 Nov '19

29 Nov '19

Hi, after now almost 12 years using, working and teaching[1] IPv6 I've come to the conclusion that IPv6 is a mistake and will not work. Therefore the RIPE IPv6 WG should be disbanded and replaced with a new WG that MUST investigate all possible solutions to artificially prolong the live of IPv4 till the day a new successor for IPv4 is created and implemented! Some great ideas[2] are already proposed, some of them already implemented: - Use of NAT - Use of the first Class-A network 0.0.0.0[3] - Use of parts of localhost Class-A network 127.0.0.0 - Use of (parts) of Class-D address space (multicast) - Use of Class-E address space (future use) - Using part of the UDP / TCP port range as extension for the address. Some of the reserved address spaces could also be used. E.g. nobody is using 192.0.2.0/24 for documentation anyway. It should also be investigated to take back legacy IPv4 resources, although the "owners" of these resources might already selling them on the open market. It MUST also be considered not filtering on Class-C[4] bounderies but going for something smaller like /26 or /27 in the global routing table. Also new Class Designations for these prefixes MUST be created. The new successor to IPv4 should not make the same mistakes as IPv6. - IT MUST have NAT - It MUST have Classes - IT MUST have DHCP - It MUST have ARP - It should be possible to drop ICMP the same impact as in IPv4. Many experts I talked to over the years told me that blocking ICMP has no negative impacts. - It MUST only have numbers and dots "." - There should be absolutly no reasons to use "[ ]" in URLs Probably the best way to proceed is to just add one or two octets to the address. One of the reasons for the above is that there are so is so many good documentation already written about IPv4! And people already know about IPv4! Why waste this knowledge and experience? There is also plenty of good software out there that can't work with IPv6[5] Change is bad! People don't want to learn! IPv4! MUST! NOT! DIE! Jens [1] at least trying to teach, as one can see from the great number of people actually using IPv6 with little success [2] https://netdevconf.info/0x13/session.html?talk-ipv4-unicast-expansions [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… [4] a Class-C network is the equivalent of an /24. I was told by experts that the definition of some bit set in the first octet of an IPv4 address is complete and utter nonsense [5] like a 20 year old shell script that is so important for $university that it would be hard for them to implement IPv6!

33 64

Fwd: SLAAC renum: Problem Statement & Operational workarounds
by Fernando Gont 23 Oct '19

23 Oct '19

Folks, Your input would be very welcome. Preferably on the v6ops wg mailing-list (https://www.ietf.org/mailman/listinfo/v6ops), but also on this list or multicast to us (authors). Thanks! -------- Forwarded Message -------- Subject: SLAAC renum: Problem Statement & Operational workarounds Date: Wed, 23 Oct 2019 03:51:32 -0500 From: Fernando Gont <fgont(a)si6networks.com> To: IPv6 Operations <v6ops(a)ietf.org> Folks, Earlier this year there was a lot of discussion about slaac renumbering problems. Our original I-D covered everything from the problem statement to proposed protocol updates and operational workarounds. Based on the comments received while discussing this topic on this list and other forums, and in order to keep the discussion better focused on specific aspects of the problem, we have posted a v6ops-targetted document that focuses on: * The problem statement * Discussion of operational workarounds, and associated constraints The document is available at: https://tools.ietf.org/html/draft-gont-v6ops-slaac-renum We'd like to hear from the wg whether we have missed anything, whether the document is useful to the community, etc. 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

Have we failed as IPv6 Working Group?
by Wolfgang Zenker 11 Oct '19

11 Oct '19

Hi, the description of the working group says: "The IPv6 Working Group is for anyone with an interest in the next generation Internet Protocol. The activities of the WG include education and outreach, sharing deployment experiences and discussing and fixing operational issues." I know we do all of this at RIPE Meetings and maybe other times as well, but still ... ... the default network at RIPE Meetings is the dual-stack network, with the IPv6-only (NAT64) network as a barely used extra which is "supported on a best effort basis". With the effect that almost no-one except a few "ipv6 zealots" uses it. This tells me that a significant part of the RIPE community does not only consider this setup "not production ready" but expects an amount of breakage so huge that it's not acceptable to try it out and see what would actually break (while still offering a dual-stack network as a fallback, of course). ... the results of the RIPE NCC survey published today lists the scarcity of IPv4 addresses as one of the largest challenges facing the participants in the survey. At the same time, about one quarter of participants has no plans for deploying IPv6, with the most common reason given as "there is no business requirement for IPv6". This tells me that a significant part of the RIPE community does not view a migration to IPv6 as a useful way to deal with the shortage of available IPv4 address space. These two examples both concern the RIPE community, a group of people that are highly interested and knowledgeable in the field of internet operations. Now think about what the situation might look like at your friendly neighbourhood IT shop or network department. I maybe wouldn't call the IPv6 WG "failed", but it clearly still has a long way to go until we can claim "mission accomplished". Wolfgang

26 68

Re: [ipv6-wg] Have we failed as IPv6 Working Group?
by Geert Jan de Groot 09 Oct '19

09 Oct '19

Folks, I've been out of the ISP business for a while now, but may I make some observations: Many of the major content providers are IPv6-enabled. The question is for end users, how to use IPv6 to access these services. In the Netherlands, there is no mobile operator providing IPv6 connectivity. None! I cannot get IPv6 on my mobile connection! Also, in the Netherlands, the one Internet-to-home provider providing dual-stack IPv6 (w/o NAT mess) is being assimilated by it's parent who, after twenty-five years, is still technologically behind and can't deliver IPv6 themselves. The mitigation to get IPv6 access for endusers who can't get IPv6 from their provider (sixxs.net) closed doors two year ago. I am not aware of any VPN-provider offering IPv6 service to allow endusers to augment the limited offering from their service provider. It isn't a matter of "switch to a provider who has", for endusers, there is *nothing to choose from*. We can do all kinds of exercises (IPv6-only event networks, eat-your-own-dogfood exercises), but there must be reasons for having a business case for not providing IPv6 to end users. Perhaps they are non-technical, but reasons they are; if there would be a business case, people would be doing it. And perhaps these (non-technical?) reasons should be something the WG can look at. A fair number of members of this WG are related to the ISP industry and perhaps can shine some light as to the "why don't you" for access providers? Geert Jan

4 3

[official] What Shall This WG Do
by Jen Linkova 08 Oct '19

08 Oct '19

Hello, dear IPv[0-9] enthusiasts, supporters and zealots, As a co-chair I'm excited to see some discussion happening here, especially after the list has been quiet for a while. I'm less excited to see that some people have started giving up hope and telling the rest of use we shall give up to.. By a lucky coincidence we have 10 mins open-mic slot during IPv6 WG session in Rotterdam to discuss what the WG is doing and what we, as a community, want it to do (however after reading all those threads I'm afraid 10 mins might not be enough). What I'd like to ask you meantime is to think what the priorities and goals are. Get IPv6 adoption to 100%? (Is it realistic? Shall we target to 100%?) Convince everyone that IPv6 is good and IPv4 shall be turned off? Provide a venue for those who are interested to discuss the topic and share the experience (including negative one? Produce documents (or recommendations?) Educate people? What should be considered as success, what is the failure and what is just a roadblock? The current WG charter is available on https://www.ripe.net/participate/ripe/wg/ipv6 Please read it and let's discuss if anything should be changed there. -- SY, Jen Linkova aka Furry

4 3