Dear IPv6 WG members,
some of you might already have read this, but I would like to bring it to the
attention of our working group:
Last week the Czech government approved a resolution, that they will stop
providing government services over IPv4 starting on 2032-06-06 [1].
This is point number 14, translated in english with the help of a translator
as I don't speak czech ;-)
--------------------CUT--------------------
14. Restarting the introduction of DNSSEC technology and the IPv6 protocol in
the state administration,
no. 25/24
Submitted by: Minister of Industry and Trade
Result of the government meeting: approved .
--------------------CUT--------------------
There is also some more information in blog articles of nic.cz [2] [3].
The end of IPv4 is near [4] (tm). A link to the details of the resolution (in
czech) is also on that page.
I hope that this announcement of the Czech government will speed up the IPv6
adoption. Ok, it's still 8 years until 2032, but there are also a lot of
companies out there who did not even think about implementing IPv6 yet.
What is your opinion about this?
[1]
https://vlada.gov.cz/cz/media-centrum/aktualne/vysledky-jednani-vlady-17--l…
[2] https://blog.nic.cz/2024/01/18/kratke-vlny-vladni-restart-podpory-ipv6/
[3] https://blog.nic.cz/2024/01/18/odvazny-krok-ceske-vlady/
[4] https://konecipv4.cz/en/
Kind regards from Berlin
Chris
Hi there,
I'm seeking some views on how I should report some web failures on my
IPv6 survey page <https://www.mrp.net/ipv6_survey/>.
If a site has both A and AAAA records for a web site I will try to
connect to the IPv6 address and see if there is a web site listening
there. It will start at tcp port 80 and then follow any redirects until
hopefully it finds a 200 response.
The cases where it gets to a 200 are fine as that's "success" but there
are some failure modes that I can't really make my mind up on so having
some feedback would be potentially useful.
In all these cases I see a site with A and AAAA records so I connect on
port 80 of the IPv6 address(es).
1. If the connection fails should I just report that or should I do
anything more? For example see if the site responds via IPv4.
2. If the connection succeeds (so I assume there should be a working
IPv6 based web server) but after querying it with a HTTP/1.1 message
sees the site resets the connection (or fails in some other manner).
3. The connection succeeds as does the query and I get a 301 redirect to
a location that fails to connect (typically it's the https port but
could be another domain name). Again is this enough or should it do
something else?
The difference is in how they are reported on the main survey page. If
there is a problem then the cell will be blue but if I stop at the error
then some indication of the error will appear in the cell. If after the
failure I check if IPv4 works then the cell will still be blue but the
indication in the cell will be the IPv4 status (more often than not this
is success and so the indicator is type of connection (HTTP, HTTPS,
HSTS, H2, etc) with a link to the web page.
At the moment I'm not consistent and I probably should be :-) but what
type of indication is more helpful?
Finally in some cases I'll get a HTTP status code such as 403, 429 or
503 rather than 200 and these are reported with a background of either
light green or light red depending on whether it occurred on an IPv6 or
IPv4 connection. Should these be blue rather than a different green/red?
Thanks,
Mark.
Hello All,
A happy new year to all of you !
below are the draft minutes from the RIPE87 meeting in Rome.
A big thank you to Matt for taking the notes
Please comment if you want any changes before Friday 12.1
Session: IPv6 Working Group RIPE 87
Date: Thursday, 30 November 11:00 - 12:30 (UTC+1)
WG co-Chairs: Benedikt Stockebrand, Jen Linkova, Raymond Jetten
Scribe: Matt Parker
Status: Draft
View the video archive<https://ripe87.ripe.net/programme/meeting-plan/ipv6-wg/>
View the stenography transcript<https://ripe87.ripe.net/archives/steno/39/>
View the chat archive<https://ripe87.ripe.net/archives/chat/39/>
1. Welcome
Raymond Jetten, IPv6 Working Group Co-chair
The presentation is available at:
https://ripe87.ripe.net/wp-content/uploads/presentations/88-IPv6-WG-Opening…
Raymond opened the session, welcomed the attendees and approved the minutes from RIPE 86. He also explained the process that would be followed for the upcoming Working Group Co-chair selection and reminded everybody to follow the microphone etiquette throughout the session.
There were no questions.
2. Co-Chair Change
Raymond Jetten, IPv6 Working Group Co-chair
Benedikt Stockebrand stepped down as IPv6 Working Group Co-chair, having fulfilled the role for nine years. Raymond thanked Benedikt for his service.
The two new candidates for the Working Group Co-chair role, Christian Seitz and Paolo Volpato, joined Raymond on stage. They briefly introduced themselves and explained to the Working Group why they would be a good choice for the role. A poll was conducted using Meetecho.
There were no questions.
3. Currently Available Solutions to Provide IPv6-based Multi-homing Connectivity
Paolo Volpato, Huawei
The presentation is available at:
https://ripe87.ripe.net/wp-content/uploads/presentations/82-IPv6-Multihomin…
Paolo gave a high level summary of the work being carried out in the IPv6 Operations (v6ops) working group in the IETF, focussing specifically on support for multi-homing in IPv6.
Gert Döring, SpaceNet AG, commented that his favourite model was the dual provider aggregatable prefix. Not only because it's less burden on the routing table, but also because it empowers the client machines to make decisions. He added that problems remain with source address selection and source address failover but that there is potential for bright solutions.
Rinse Kloek, Delta Fiber, agreed with Gert and stated that he is not a big fan of using PI space for multihoming. This is due to the impact that it could have on the growth of the global routing table.
Urban Suhadolnik, TU Graz, asked whether they had looked into mobile IP extension? Paolo replied that that they had not yet, but that it is something they can consider.
Jan Zorz, 6connect, commented that if we use PA space, and one of the CPE dies, then the neighbor reachability protocol will take care of switching to the other gateway. He added that the source selection mechanism is still fundamentally broken, but work is ongoing at the IETF to address this. Finally, he recommended a draft from Jen Linkova to address the problem of a CPE coming back to life and receiving a different prefix. Jen stated that it is a functioning solution and Jan offered to help with the next steps.
Jen Linkova, asked in her personal capacity, whether we should focus on a limited number of scenarios, covering perhaps 80% of our current use cases, rather than trying to consider all possible scenarios? Jen also responded to Jan's comment about host gateway tracking by stating that she believes both Microsoft Windows and Apple do this already, and that some work is happening on Linux. Once the Linux problem is solved most of the normal host operating systems will be covered.
Brian Turnbow, twt spa, observed that he had received three different tenders over the last year where they had their own AS number and their own, de-aggregated, /48 assignment. He explained that the tenders came from multinational American companies who were assigning /48s worldwide to different sites, all from their own block. He commented that he had not seen it yet from any European companies.
There were no further questions.
4. What's New on the IPv6 Front at the IETF?
Eric Vyncke, Cisco
The presentation is available at:
https://ripe87.ripe.net/wp-content/uploads/presentations/102-20231130-RIPE-…
Eric provided an update about what is new on the IPv6 Front at the IETF.
Jan Zorz stated that he really likes the idea of prefix delegation to every host, if every host has a /64 you could run a web server on IP, so there would be no need for IP ports.
Tom Hill, BT, commented that he is a co-author on the Trusted Domain SRv6 draft which is seeking an optional ether type for SRv6. He stated that the reason he did this is that the Micro-SID draft would allow you to forgo the SRH in the packet, which he found concerning.
Jordi Palet Martinez, The IPv6 Company, mentioned that there is a draft being updated which is important to the community - RFC 7084, Basic Requirements for IPv6 Customer Edge Routers.
Tobias Fiebig, MPI-INF, mentioned two additional drafts. The first is updating the DNS trans record requirements making IPv6 an equal citizen to IPv4, which Tobias commented was long overdue. The second deals with IPv4 via IPv6 next hops which we have for NLRI and BGP announcements.
There were no further questions.
5. Deployment of 464XLAT in a Medium-sized Operator
Jordi Palet Martinez, The IPv6 Company
The presentation is available at:
https://ripe87.ripe.net/wp-content/uploads/presentations/104-464XLAT-deploy…
Jordi discussed his experiences deploying 464XLAT in a medium sized operator.
Michael Richardson, Sandelman Software Works Inc, explained that one of the problems he had discovered with his dual-stacked network was troubleshooting IPv4 only customers. He asked Jordi whether he sometimes had to undo dual stack on them to find out what was broken? Jordi replied that it is sometimes necessary to disable either IPv4 or IPv6 to investigate a problem, but in general it wasn't too much of a problem.
Rinse Kloek asked whether Jordi had found a CPE vendor that supported the CLAT part of 464XLAT. Jordi responded by stating that he is one of the authors of RFC 8585 (Requirements for IPv6 Customer Edge Routers to Support IPv4-as-a-Service) and that the other two authors are both vendors who support it. However, he agreed that it may be necessary to speak with the vendor regarding specific configuration requirements and mentioned that not all customers will be happy using open source for this.
Urban Suhadolnik asked Jordi for clarification on the APNs with Apple that he mentioned. Is it correct that there is an OTA from Apple that updates them? Jordi replied that no, you need to have an OTA platform on your network. Urban stated that he was also asking for Android because the configuration is already there, it is in the OS when you get the phone. Jordi agreed that it is much easier in Android, if they see that they can choose IPv6 it just works, there is no need to change the PDP type manually.
There were no further questions.
6. Thanks, Wrap Up and Rate the Talks [5 min]
Raymond and Jen announced the result of the Working Group Co-chair selection, Christian Seitz was selected.
Raymond reminded everybody to rate the talks at RIPE 87 and Jen asked the working group to submit talks for RIPE 88 in Krakow. The session was closed.
For Internal Use Only
