- ipv6-wg - mailman.ripe.net

Fwd: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum
by Fernando Gont 04 Apr '20

04 Apr '20

Hello, folks, v6ops is WGLC'ing one of the documents (https://tools.ietf.org/html/draft-ietf-v6ops-cpe-slaac-renum-01) we have authored to improve the reaction of SLAAC to renumbering events. This document contains recommendations for Customer Edge Routers. For background, you may want to consult: https://tools.ietf.org/html/draft-ietf-v6ops-slaac-renum-01 If you have any comments/feedback, please do let us know. If possible, on the v6ops list (https://www.ietf.org/mailman/listinfo/v6ops) Thanks! Cheers, Fernando -------- Forwarded Message -------- Subject: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum Date: Mon, 30 Mar 2020 15:47:14 +0000 From: Ron Bonica <rbonica=40juniper.net(a)dmarc.ietf.org> To: v6ops(a)ietf.org <v6ops(a)ietf.org> Folks, This message initiates a WG Last Call on draft-ietf-v6ops-cpe-slaac-renum. Please submit comments by April 13, 2020. Fred and Ron Juniper Business Use Only -- 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

3 3

New on RIPE Labs: What’s the Deal with IPv6 Link-Local Addresses?
by Philip Homburg 11 Mar '20

11 Mar '20

Dear colleagues, Stephen Strowes, Emile Aben and I published a new article on RIPE Labs on how link-local addresses in IPv6, and specifically the '%eth0'-part of link-local addresses, can have an impact on RIPE Atlas measurements. https://labs.ripe.net/Members/philip_homburg/whats-the-deal-with-ipv6-link-… We think this will be an interesting read for network operators and others who are using RIPE Atlas measurement data or are interested in IPv6. Kind regards, Philip Homburg RIPE NCC

2 1

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