Re: [ipv6-wg] RIPE 88, presentations and a co chair change.....
united by Postbank/Deutsche Bank, new relic, ns1, ibm, fastly and others To blame fastly wasn't right. That was my fault. Thank you Job Snijders for clarification. Regards, Thomas -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/ipv6-wg
Re: [ipv6-wg] IPv4-mapped addresses in AAAA records
Hi Ondřej, I can remember, you helped me to examine the impact of this problem. "New relic" provides its services unfortunately to a lot of customers. Of course I try to send the message: If you do IPv6, please do it right. Maybe that kind of problems is better placed at MAT-WG. I have also seen dns64-records with well known prefix at authoritative DNS servers, but I can't remember where. There are a lot of crazy things out there, we can learn from. Regards, Thomas -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/ipv6-wg
Re: [ipv6-wg] RIPE 88, presentations and a co chair change.....
Am Donnerstag, 21. März 2024, 11:52:36 CET schrieb Raymond Jetten: > Dear IPv6 wg list members. > > In about 2 months, we will meet in Krakow, and ofcourse online. > > We still need presentations for the meeting, a I can't present, but I would suggest the topic: Lessons learned/ Lessons not learned - the mess with mapped IPv4 addresses - or just Layer 8 problems: Lessons learned: https://www.githubstatus.com/incidents/5y8b8lsqbbyq Lessons not learned: united by Postbank/Deutsche Bank, new relic, ns1, ibm, fastly and others https://forum.newrelic.com/s/hubtopic/aAX8W015BUvWAM/bamnrdatanet-resolves-with-wrong-records Regards, Thomas -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/ipv6-wg
Re: [ipv6-wg] IPv6 mobile deployment
Am 11.10.23 um 11:20 schrieb Geert Jan de Groot: Hi, May I ask a different, but related question: While IPv6 migration on classic networks (server farms, internet-at-home connections) is ongoing (and has been ongoing for many, many years, alas), we don't seem to make any progress with mobile data networks. In Germany all three mobile networks provide ipv6 (Telekom 2015(dualstack)/2020(v6-only), Vodafone 2019(dualstack), O2 2021(dualstack)). You may travel over the border and buy a sim here ;-) Roaming in NL works with all three German mobile network operators in dualstack mode except for 2G/3G. Regards, Thomas https://atlas.ripe.net/probes/1000234/ https://atlas.ripe.net/probes/53236 https://atlas.ripe.net/probes/1000568/ -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/ipv6-wg
[ipv6-wg] IPv6-mostly IPv6-only(with dns64/nat64) dual stack at RIPE-meeting
Hi, during the closing plenary were considerations to remove the IPv6-only(with dns64/nat64) network/ssid the next time. I would vote for that. IPv6-mostly covers the traditional IPv6-only. Someone made the proposal to provide a real "ipv6 only" net/ssid instead (without nat64) My first thought was: Never, it will the people just frustrate. My second thought was: Let's try it! After the first shock - only 50% of the websites support IPv6 - we should provide tips for testing: - using public dns64 with own nat64 address space - VPN, the public ones like apple privacy relay, cloudflare warp ... - VPN, own organisation/company like eduvpn for NREN (e.g. DFN supports it, other institutes too, cisco anyconnect... -VPN personal, like wireguard/ipsec to AVMs fritzbox and others, openvpn NAS/ own setups Last but not least I propose to provide that special DNS-resolver: https://gitlab.com/miyurusankalpa/IPv6-dns-server It increases the amount of IPv6 capable destinations. Regards, Thomas -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/ipv6-wg
Re: [ipv6-wg] web services to ipv6
Am 14.10.22 um 11:15 schrieb Gery Escalier via ipv6-wg: I am interested for personal use. -Free IPv4/IPv6 BGP tunnel -Public NAT64 server available at 2602:fc23:18::7 -Public Teredo server available at teredo.august.tw Their NAT64 service works in an unusual(ipv4 address isn't embedded at the end) but allowed( https://www.rfc-editor.org/rfc/rfc6052#section-2) way. -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/ipv6-wg
Re: [ipv6-wg] Rquirements for VPN
Am 28.10.20 um 22:09 schrieb christian bretterhofer: After reading https://go6.si/wp-content/uploads/2020/10/RIPE554-bis-v_01.pdf I see VPNs as part of the Network Security Equipment. But in my opinium there is not enough definition to be a VPN quality criteria. Protocols with DNS64/NAT64 support would also help. maybe it fist into this recommendation document. I think that is already covered by VPN external Protocol Must support IPv6 clients to IPv6 servers (6-to-6) ( Ipv6 Only) and VPN inner Protocol Must support IPv6 clients to IPv6 servers (6-to-6) Maybe it should be mentioned the every day problems called "... leaks" ... IPv6, DNS (also important, if DNS64 is in use) and IPv4 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
Re: [ipv6-wg] New on RIPE Labs: What’s the Deal with IPv6 Link-Local Addresses?
Am 11.03.20 um 11:40 schrieb Philip Homburg: https://labs.ripe.net/Members/philip_homburg/whats-the-deal-with-ipv6-link-local-addresses Thank you for this good explanation. I disagree with one thing: "The reason is that the use of link-local addresses for DNS resolvers is quite rare" I have seen a lot of such setups. (some LTE-Routers, fritzboxes without Unique Local Unicast and speedports) "For anchors and software probes, the measurement code will use whatever it finds in /etc/resolv.conf. So far, none of those contained link-local addresses." That will be changed tonight :-) 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
Re: [ipv6-wg] Disband IPv6 WG
Am 23.10.19 um 15:26 schrieb Fernando Gont: It's worse than that: Most IPv4 CPE devices have UPnP support, but IPv6 ones often lack the hooks to punch holes into the fw. SO at the end of the day you get better end-to-end connectivity with IPv4 than with IPv6 That assumes you have at least a public ipv4 address at your home router. A a lot of people (in Germany) cannot fulfill this requirement. Some of them hope/pray for pcp instead of UPnP. (good luck) On the other hand, despite most home routers have a simple firewall - people may change their routers. And cheap router may get an software update, as they got it in former time for dyndns and port forwarding... -- 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
Re: [ipv6-wg] Have we failed as IPv6 Working Group?
By the way: *single* SSID, What is the reason to provide "ripemtg" and "ripemtg-2.4-79"? Outside of Ripemeetings I don't see different IDs for the different wifi frequencies. e.g. the eduroam in Munich, with daily 5 Users in peak, works fine without two separate SSIDs
Re: [ipv6-wg] Have we failed as IPv6 Working Group?
Am 08.10.19 um 18:14 schrieb Wolfgang Zenker: On the other hand, switching the "default" meeting SSID to IPv6-only/NAT64 while still providing the dual stack network as a fallback, preferably combined with a helpdesk staffed by volunteers ready to analyze any problems that attendees might have, strikes me as a pretty good opportunity to raise awareness and to find problems where further work is needed. I would be a volunteer at ripe80, provided the DNS64/NAT64-Gateway isn't overbooked. That should be easy to ask 10 people. (the other 890 will not have problems at all) Do you want to investigate the problem? Do you want just switch to the classic network? Nobody will be without network and "we" would get an overview, where the problems are. 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
Re: [ipv6-wg] Have we failed as IPv6 Working Group?
You should know the difference between IPv6-only mailhosts and IPv6-only Wi-Fi + DNS64/NAT64.ThomasAm 08.10.2019 05:29 schrieb Job Snijders :On Mon, Oct 07, 2019 at 08:11:41PM +0200, Enno Rey wrote: > On Mon, Oct 07, 2019 at 08:05:18PM +0200, Bjoern Buerger wrote: > > * Martin Schr?der (mar...@oneiros.de) [191007 19:13]: > > > Am Mo., 7. Okt. 2019 um 18:04 Uhr schrieb Dave Taht : > > > > If I can get *one* person in this working group to go down to > > > > their local coffee shop and make ipv6 work by whatever means > > > > necessary (and > > > > > > Please start by eating your own dog food and make future RIPE > > > meetings IPv6 only. > > > > +1 > > > > Bj?rn > > we should definitely have a discussion about this in the 'open mic' > slot in the wg in Rotterdam. Let's identify who to talk to, from the > meetings' NOC and other circles within RIPE NCC, beforehand. If folks are serious about killing dual-stack ... Wouldn't it make more sense to first move this mailing list to an actual ipv6-only environment? Perhaps the WG could RIPE NCC to register a domain like ripe-ipv6-only-wg.org. This domain would have authoritative nameservers only reachable via IPv6, an MTA that doesn't have any IPv4 connectivity & a webserver with the charter, CoC, and mailing list archive only accessible via IPv6. Much like how Marco David's dnslabs.nl is set up? Kind regards, Job
Re: [ipv6-wg] Useful Information / RIPE78
Hi, Thank you for the video link. It solves my problem. "DNS-over-TLS Resolvers are available at RIPE 78 on a best-effort basis. They are available on TCP port 853, on the same IPv4 / IPv6 addresses as the regular DNS resolvers" lets me think about only regular resolvers. I didn't know or I forgot, DNS64 is provided based on the querying address by ACL. So I can test both features at the same time. @Colin Maybe you add the link https://ripe76.ripe.net/presentations/96-dns-over-tls-resolvers.pdf here https://ripe78.ripe.net/on-site/tech-info/dns-over-tls-resolvers/ @Gert I have no doubt that native IPv6 will work at RIPE, independent of the way IPv4 is added. In the worst case your are right, I can fetch my IPv4-access from m-net, lrz or Go6lab(JanZorz). Thomas
[ipv6-wg] Useful Information / RIPE78
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
Re: [ipv6-wg] IPv6 ipsec tunnel server on linux server
Hi, May be my last comment on that topic. Everything with UDP und ipsec leads to RFC 3948, the workaround for IPv4 and NAT. But for some reasons esp-pakets are also blocked by some ISP via IPv6. One of the questions was if linux supports udp encapsulation. I am not sure, if my thoughts complete nonsense. https://people.netfilter.org/pablo/netdev0.1/papers/UDP-Encapsulation-in-Linux.pdf https://www.netdevconf.org/0.1/docs/herbert-UDP-Encapsulation-Linux.pdf may also useful for ipsec(ESP/AH) over udp over ipv6. If only used in manual configurations or also automated with free/libre/ strongSwan-forks. I don't know. Regards, Thomas
Re: [ipv6-wg] IPv6 ipsec tunnel server on linux server
Am 05.11.18 um 11:39 schrieb Michael Hock: https://wiki.strongswan.org/issues/939 This is about NAT/NAT64 on ipsec transport. Despite a (im)possible (Linux?) udp encapsulation I wouldn't do that. NAT64 can avoided by IPv6-IPv6 direct connections. and (CG)NAT
Re: [ipv6-wg] Still open for discussion: Invitation to supply feedback on ITU draft Recommendation on IPv6 address planning for IoT
Am 24.05.2018 um 09:18 schrieb Mikael Abrahamsson: Some comments: "Editor notes: there are a large number of ipv4-ipv6 transition and migration strategies: Teredo, 6to4, etc. " I'd just like to point out that Teredo and 6to4 aren't migration strategies, they were basically a way to beta-test the technology. Please do not mention them, we're way past beta testing of IPv6. Mention things like 6RD, MAP, NAT64, ds.lite etc. I still see people thinking 6to4 is something that should be deployed today. RFC3068 is already obsoleted by RFC7526 (a 2015 RFC). So far so good. But in my humble opinion 6rd plays in the same class as all other ipv4-based tunnels are doing. Of course isatap and 6rd may better monitored but they still depending on ipv4. Please exclude 6rd in your recommendation. Regards, Thomas
