Dear WG IPv6,
We are writing to share with the RIPE community our research work on IPv6 and we would appreciate having feedback from you.
If you find it useful, we are also available to present it at the next RIPE meeting in order to stimulate further discussion on this topic.
In this regard, we have presented a draft in IETF V6OPS WG (https://datatracker.ietf.org/doc/draft-vf-v6ops-ipv6-deployment/) and it should be discussed during the coming IETF 110.
In summary, the draft describes where the adoption of IPv6 stands in different domains (operators, enterprises, content providers, etc.), highlights possible steps to move the deployment of IPv6 forward, tries to stimulate the discussion on possible “calls for action” to further push the shift to IPv6, and presents some misconceptions as well as open points still to be faced related to that.
Some key findings of our work show that open aspects still remain, for which we would be happy to have the feedback of the RIPE community:
1. IPv4 exhaustion: the total remaining IPv4 address pool, as reported by the five RIRs at the end of 2020, has a bit more than 18 million addresses (either available or reserved). This data is summarized for example in https://www.potaroo.net/ispcol/2021-01/addr2020.html. However, from the same article, it appears that the pool of unadvertised addresses has grown in the past few years. Quoting it: “From 2018 to the end of 2020 this pool rose to around 50 /8s that were unadvertised in the public Internet”. On the one hand this seems a good sign for IPv6 deployment (e.g. IPv4 addresses are released). On the other, we may suspect that the IPv4 addresses are more than expected and that available space could be used, for example, for transfers. We would like to have your opinion on this.
2. IPv6 performance (latency, packet loss) seems, in some cases, worse than IPv4. Clearly, the perception of “bad” performance (relatively) might have a negative influence over the adoption of IPv6. What is the opinion of the community on this point?
3. IPv6 for Enterprises and Vertical Industry also shows a low level of deployment that can be investigated.
4. More could also be added.
We would be happy to discuss that with you. As said, we are also available to present our findings at the next RIPE meeting to bring it further.
Many thanks in advance
BR
Paolo
Paolo Volpato
Senior IP Product Manager
Europe Standardization & Industry Development Dept [2012 Labs]
____________________________________________________________________________
Huawei Technologies
Address: via Lorenteggio 240, Torre A, 20147 Milano Italy
Mobile: +39 344 019 7606
E-mail: paolo.volpato(a)huawei.com
_____________________________________________________________________________
Huawei Technologies Italia S.r.l. is a company registered in Italy at the Company Registration Office of Milan, with registered number 04501190963 and equity capital €3,000,000 fully paid up, whose registered office is in Milan, Via Lorenteggio 257, Tower B, 20152 Milan. Huawei Technologies Italia S.r.l. is 100% owned by Huawei Technologies Cooperatief U.A
_____________________________________________________________________________
This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
PRIVACY NOTICE: Pursuant to Art. 13 of Legislative Decree 196/03, so called "Data Protection Code", Huawei Technologies Italia Srl. informs you that the personal data provided by you will be treated for the acquisition of information preliminary to the conclusion of contracts, for the definition and formalization of contractual relationship with you as well as for their management and for the fulfillment of legal requirements related to civil, tax and accounting law. Data are processed both through computer or paper in a lawful and correct manner and in compliance with the Decree. Personal data and its processing are necessary for business negotiation and will not be subject to disclosure and spread out the circumstances permitted by law, on the same you can exercise your rights under art. 7 of the above mentioned decree. The Data Controller is Huawei Technologies Italia Srl, which has appointed Data Processors, the list of which is available at dataprotection(a)huawei.com<mailto:dataprotection@huawei.com>.
Hello,
RIPE82 will be virtual, from May 17th till may 21th. The IPv6 Working
Group is tentatively scheduled for May 20th, 10:30 - 12:00 CET (UTC+2).
We are looking for talks - please email ipv6-wg-chair at ripe.net<https://lists.ripe.net/mailman/listinfo/ipv6-wg> if
you'd like to present.
Thanks!
Jen, Benedikt, Ray
Hi all,
We've published a study on the stability of IPv4/IPv6 assignments in
domestic ISPs, and the size of the IPv6 prefixes that networks typically
assign to subscribers. We look at this from two different angles: what
can we measure from RIPE Atlas, and what do operators state in the RIPE
Database?
In particular, understanding the size of IPv6 delegated prefixes is
important for applications such as host reputation & blocklists,
geolocation, and research on network measurement. The RIPE Database
offers the community a way to share information on their prefix
delegations, and deserves some attention!
Read more here:
https://labs.ripe.net/Members/stephen_strowes/address-assignment-practices-…
Cheers,
S.
Folks,
FYI:
https://tools.ietf.org/html/draft-gont-v6ops-ipv6-addressing-considerations
Comments welcome. :-)
Thanks!
Cheers,
Fernando
-------- Forwarded Message --------
Subject: IPv6 Addressing Considerations
Date: Fri, 11 Dec 2020 13:07:04 -0300
From: Fernando Gont <fgont(a)si6networks.com>
To: IPv6 Operations <v6ops(a)ietf.org>
Folks,
We have published a new Internet-Draft entitled "IPv6 Addressing
Considerations".
It is available at:
https://www.ietf.org/archive/id/draft-gont-v6ops-ipv6-addressing-considerat…
The Abstract of the I-D is:
IPv6 addresses can differ in a number of properties, such as scope,
stability, and intended usage type. This document analyzes the
impact of these properties on aspects such as security, privacy,
interoperability, and network operations. Additionally, it
identifies challenges and gaps that currently prevent systems and
applications from leveraging the increased flexibility and
availability of IPv6 addresses.
We have discussed this topic with some of you off-list, and part of
those comments still need to be incorporated (apologies for the delay!).
However, we felt that this -00 version already contains quite a bit of
material for discussion. (and given that there have been other recent
threads related to IPv6 addressing on this list and on 6man@, we felt it
would be timely to get this -00 version posted now).
Your comments will be very welcome.
Thanks!
Regards,
--
Fernando Gont
SI6 Networks
e-mail: fgont(a)si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
Dear Working group,
Below are the draft minutes from ripe 81.
If you have any comments or remarks please let us know by replying to this email.
A big thanks to Nikolas for doing the scribe.
If we do not hear any comments these minutes will be published in about 2 weeks from now.
Rgds,
Ray, Jen, Benedikt.
IPv6 Working Group Minutes - RIPE 81
Date: 29 October 2020, 13:00 - 13:45
WG Chairs: Benedikt Stockebrand, Jen Linkova, Raymond Jetten
Scribe: Nikolas Pediaditis
Status: Draft
Welcome - Agenda Bashing
The Chairs
The minutes of IPv6 Working Group session from RIPE 80 were accepted as final. There were no questions or comments.
RIPE554-bis - Tim Chown
The presentation is available here:
https://ripe81.ripe.net/presentations/58-ripe81-ipv6wg-ripe554bis-final.pdf
Dmitry Serbulov (Alpha Net Telecom LTD) asked if it would be possible to share material with attendees prior to the start of each session.
Raymond Jetten suggested that he should join the IPv6 WG mailing list.
Bringing IPv6 Everywhere - Nico Schottelius
The presentation is available here:
https://ripe81.ripe.net/presentations/73-ripe81-bringing-ipv6-everywhere.pdf
Ondrej Caletka (RIPE NCC) asked if connectivity will break if the host network becomes dual-stacked, or at worst, if the host network becomes IPv6-only.
Nico replied that it wouldn't. IPv4 connectivity would still be available, and IPv6 would be added to it.
Kurt Kayser (BDBOS) asked if geo-IP will always show that the VIIRB-users are in Switzerland.
Nico Schottelius replied that at the moment, yes. And there is a bracket opening as soon as they are able to talk better to the RIPE API to change the registration of the /48 networks. It will be easy to actually assign the network to your location.
Christoph Berkemeier (DB Station&Service AG) asked if the IPv6 distribution is stateless only.
Nico confirmed that it is stateless at the moment but that could be changed if desired.
Veronica McKillop (UK IPv6 Council) asked where the device is being manufactured.
Nico replied that it's manufactured in China and shipped to and configured in Switzerland.
Dmitry Serbulov (Alpha Net Telecom LTD) asked if open source software is used between the device and the server it connects to.
Nico said that the software used, WireGuard and OpenWRT at the moment, are fully open source.
Vesna Manojlovic (RIPE NCC) mentioned that a hackathon about RIPE Atlas software probes is taking place in November. She asked if Nico would be interested in joining and seeing how they could combine his router with RIPE Atlas software probes if possible.
Nico replied that it would be a really cool project.
Christoph Berkemeier (DB Station&Service AG) asked if there is a virtual appliance to enable legacy hosters.
Nico replied that it builds on top of your existing IPv4 network so everything that's legacy continues to work. It's not a replacement. The nice thing about IPv6 is that although it is incompatible to IPv4 this also means that it runs in parallel to the existing infrastructure, allowing the legacy network to continue to work.
Recent Improvements in IPv6 Addressing - Fernando Gont
The presentation is available here:
https://ripe81.ripe.net/presentations/72-fgont-ripe81-ipv6-wg-ipv6-addressi…
Osamah Barakat (Siemens AG) asked if Windows 10 supports the latest IPv6 RFC or it is only Linux-based OS that support seen in the slide.
Fernando Gont replied that it's surprising that they don't support RFC 7217 as one the authors worked for Microsoft. They also haven't implemented the update of 4941 either. However, he was less concerned about 4941, as compared to the support for 7217, as it has not been published as an RFC.
End of the session.
Trying to reply to all previous email messages in one email ;-)
Look for EV>
-éric-happy-to-see-this-initiative
-----Original Message-----
From: ipv6-wg <ipv6-wg-bounces(a)ripe.net> on behalf of Tim Chown via ipv6-wg <ipv6-wg(a)ripe.net>
Reply-To: Tim Chown <Tim.Chown(a)jisc.ac.uk>
Date: Wednesday, 28 October 2020 at 18:19
To: "ipv6-wg(a)ripe.net" <ipv6-wg(a)ripe.net>
Subject: [ipv6-wg] RIPE554-bis
Hi,
I’m posting here as a heads-up that an effort has begun to revise RIPE-554, involving the original authors, myself and Tim Winters. We have a 5 min slot tomorrow in the 1pm CET IPv6 WG session to flag the work, to solicit input.
The original publication was back in November 2010 with RIPE-501, which was updated in June 2012 with RIPE-554.
There’s many references that have been obsoleted, and potentially much to add or remove. References to 2G cellular date the document.
We’d like to begin by addressing the more strategic / structural questions. Such high level questions include:
- Is there agreement to progress a –bis version now? Eight years have passed, people ask for guidance…
EV> YES, please do ! knowing that RIPE554 was already a -bis, I would prefer a 501-ter though ;-)
- Should we keep the scope to (largely) enterprise or expand it? If so, to what?
EV> large/medium enterprise should indeed be the focus, consumer do not care and (wishful thinking ?) providers know better. Although, that I would love to see the IPv6 check-list for a smart TV ;-)
- Is the linkage to the IPv6 Ready Logo programme still desired?
EV> a couple of months ago, I check with several end-users and vendors, and, yes, it is still important (to be surprise to be honest, sorry Tim W)
- Are there new classes of equipment to add, e.g. IoT/low power, WiFi controllers, …?
EV> perhaps extend to applications? Cloud providers ? Perhaps remove consumer switch, load balancer, and network security ?
- Are specific sections outdated, or are there significant new sections to add?
EV> many "recents" RFC (including RFC 8200), focus on RA extensions
- Should we add guidance on applying the content to different use cases? As separate docs? Appendices?
We’ve currently working on the -bis as a Google doc, for which there’s a PDF of the current snapshot available from:
https://go6.si/wp-content/uploads/2020/10/RIPE554-bis-v_01.pdf
For now, please comment to the list, and maybe start a new thread for new topics.
Tim
Hello WG,
I have a question for those of you that offer some kind of hosting.
Do you charge your customers extra for IPv4 or IPv6 addresses? And if
you have changed your policy on that recently, did that change your
customers behaviour regarding their choice on ordering and publishing
IPv4 / IPv6 addresses for the hosted services?
Reason for asking: At our own hosting services we started out offering
dual stack by default some 6 years ago, moved to ipv6-only by default
about 2 years ago and since about one year we are charging extra for
IPv4 addresses. This has led to a change in behaviour in our customer
base, and I want to see if others are seeing similar changes or a
different situation.
You can reply off-list and I will summarize the results to the group.
Please state if I should mention your name in the summary.
Greetings,
Wolfgang Zenker
--
punkt.de GmbH Tel. +49 721 9109-500 Fax: -100
.infrastructure info(a)punkt.de https://infrastructure.punkt.de/
Kaiserallee 13a CEO: Jürgen Egeling, Daniel Lienert, Fabian Stein
D-76133 Karlsruhe AG Mannheim HRB 108285
Hi,
I’m posting here as a heads-up that an effort has begun to revise RIPE-554, involving the original authors, myself and Tim Winters. We have a 5 min slot tomorrow in the 1pm CET IPv6 WG session to flag the work, to solicit input.
The original publication was back in November 2010 with RIPE-501, which was updated in June 2012 with RIPE-554.
There’s many references that have been obsoleted, and potentially much to add or remove. References to 2G cellular date the document.
We’d like to begin by addressing the more strategic / structural questions. Such high level questions include:
- Is there agreement to progress a –bis version now? Eight years have passed, people ask for guidance…
- Should we keep the scope to (largely) enterprise or expand it? If so, to what?
- Is the linkage to the IPv6 Ready Logo programme still desired?
- Are there new classes of equipment to add, e.g. IoT/low power, WiFi controllers, …?
- Are specific sections outdated, or are there significant new sections to add?
- Should we add guidance on applying the content to different use cases? As separate docs? Appendices?
We’ve currently working on the -bis as a Google doc, for which there’s a PDF of the current snapshot available from:
https://go6.si/wp-content/uploads/2020/10/RIPE554-bis-v_01.pdf
For now, please comment to the list, and maybe start a new thread for new topics.
Tim
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.
VPN external Protocol Must support IPv6 clients to IPv6 servers (6-to-6) (
Ipv6 Only)
VPN external Protocol Must support IPv4 clients to IPv4 servers (4-to-4)
(Ipv4 only)
Transport inside of VPN
VPN inner Protocol Must support IPv6 clients to IPv6 servers (6-to-6)
VPN inner Protocol Must support IPv4 clients to IPv4 servers (4-to-4)
VPN inner Protocol should support Dual stack.
VPN inner Protocol should support 4in6 6in4 (transition protocols)
The Idea from wireguard is maybe also a should the external protocol switch
from Ipv6 to Ipv4 or Ipv4 to Ipv6 then the inner protocol should stay
connected.
Protocols with DNS64/NAT64 support would also help.
maybe it fist into this recommendation document.
--
---
best regards
Christian Bretterhofer
Enterprise User:
