RIPE 88, presentations and a co chair change.....
Dear IPv6 wg list members. In about 2 months, we will meet in Krakow, and ofcourse online. We still need presentations for the meeting, and we also need candidates to be our new collegue. For both you can send us (the chairs) your either presentation proposals or let us know that you are interested in becoming an IPv6-wg co chair. See our previous messages: Hello All, RIPE 88 will be held in Krakow, Poland from 20-24 May 2024, as well as online. For any participation form you can register here: https://ripe88.ripe.net/attend/register/ The IPv6 Working Group session is scheduled for Thursday 23 May from 11:00 . 12:30 (UTC+1) We are looking for presentations - please email : ipv6-wg-chair (at) ripe.net if you'd like to present. Please also state if you intend to be online or onsite, and the duration of your presentation, and a short description of it. Once we have decided on the agenda, we'll contact the presenters closer to the meeting. Hope to see as many of you as possible, On behalf of the IPv6-WG Christian, Jen, Ray And the co-chair position: Dear IPv6 Working Group, Jen Linkova, who has been one of the co-chairs of the IPv6 Working Group since RIPE 69 has announced she wishes to step down at the RIPE 88 meeting in Kraków, at the end of her term. Thus, we have a call for candidates. The term of a IPv6 WG co-chair is three years. A current co-chair may stand for re-selection at the end of their term or may resign voluntarily at any time. What is the IPv6 WG doing: The working group activities may be anything useful in helping people to deploy IPv6, and to manage IPv4/IPv6 co-existence. These activities include: Outreach Education Sharing deployment experiences Discussing and fixing operational issues The co-chairs also prepare the program for the IPv6 WG session at the ripe meetings. The working group will cooperate with operators and others, both inside and outside the networking industry, to share resources and combine efforts. The tasks and expectations of a WG co-chair are described here: https://www.ripe.net/publications/docs/ripe-692 A WG co-chair must comply with the Code of Conduct: https://www.ripe.net/publications/docs/ripe-766 If you feel you are interested in this or have any questions on this, you can drop the current co-chairs a note: ipv6-wg-chair at ripe.net We kindly request you to respond at latest Friday 3-May-2024 midday CET (Amsterdam), when the call for candidates will be closed. After this we will announce the candidates on the list, and you can express your support or concerns. However, the official selection will take place at the RIPE 88 Meeting in Kraków during the IPv6 Working Group session. On behalf of the IPv6 WG co-chairs, Christian, Jen, Raymond RIPE IPv6 Working Group co-Chair To the co Chairs: ipv6-wg-chair@ripe.net<mailto:ipv6-wg-chair@ripe.net> To the mailing list: ipv6-wg@ripe.net<mailto:ipv6-wg@ripe.net> For Internal Use Only
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/aAX8W0000015BUvWAM/bamnrdatanet-resolv... Regards, Thomas
+1 -- Marcin Gondek / Drixter http://fido.e-utp.net/ AS56662 ________________________________ Od: ipv6-wg <ipv6-wg-bounces@ripe.net> w imieniu użytkownika Thomas Schäfer <tschaefer@t-online.de> Wysłane: poniedziałek, 25 marca 2024 10:06 Do: ipv6-wg@ripe.net <ipv6-wg@ripe.net> Temat: 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/aAX8W0000015BUvWAM/bamnrdatanet-resolv... 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
On 25/03/2024 10:06, Thomas Schäfer wrote:
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/aAX8W0000015BUvWAM/bamnrdatanet-resolv...
Hey Thomas, I think this is a great topic and somebody should definitely cover it. I remember setting up a couple of test sites to prove wrong the claim: "We use IPv4-mapped AAAA records in order to save money on our authoritative DNS provider who charges us per query." https://ipv4-mapped.0skar.cz/ - this has only IPv4-mapped AAAA record - should be unreachable https://ipv4-mapped-pref.0skar.cz/ - this is "Postbank-style" dual stack with A and IPv4-mapped AAAA record - everybody should reach the A record website However, my macOS 14.4 on IPv6-only network happily connect to both test sites from all browsers and even prefers IPv4-mapped AAAA over A records. So the aforementioned claim may not be completely wrong (though it is still stupid). Any volunteer willing to try common OS behaviour while counting the number of DNS queries? :) -- Best regards, Ondřej Caletka RIPE NCC
Am 26.03.2024 um 12:19:55 Uhr schrieb Ondřej Caletka:
https://ipv4-mapped.0skar.cz/ - this has only IPv4-mapped AAAA record - should be unreachable
Reachable from the web browser (Pale Moon), but not ping. Browser converts the mapped IPv6, ping doesn't. telnet and ncat do. So I now know why some DNS admins use that. -- kind regards Marco Send unsolicited bulk mail to 1711451995muell@cartoonies.org
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
Am 26.03.2024 um 13:27:37 Uhr schrieb Thomas Schäfer:
There are a lot of crazy things out there, we can learn from.
That is interesting. What are other faults people did you noticed? -- Gruß Marco Send unsolicited bulk mail to 1711456057muell@cartoonies.org
My take home from this github incident is that one should do IPv6 deployment first, and then treat IPv4 as a subset via mapped IPv4 addresses. (Open)SSH had been using the mapped addresses for ages, and they showed up that way for ages. It has stopped for unknown reasons. -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS*
Hi, On Wed, Mar 27, 2024 at 02:34:41PM +1100, Michael Richardson wrote:
My take home from this github incident is that one should do IPv6 deployment first, and then treat IPv4 as a subset via mapped IPv4 addresses. (Open)SSH had been using the mapped addresses for ages, and they showed up that way for ages. It has stopped for unknown reasons.
I guess that someone was upset with the way they showed up in the logs... (OpenVPN has extra code to ensure that "we received an IPv4 connection on a dual-stack IPv6 socket" gets logged the same as "IPv4 on IPv4 socket", because that reduces the number of confused users down...) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer, Ingo Lalla, Karin Schuler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
participants (7)
-
Gert Doering
-
Marcin Gondek
-
Marco Moock
-
Michael Richardson
-
Ondřej Caletka
-
Raymond Jetten
-
Thomas Schäfer