Merge branch 'master' of git+ssh://code.ungleich.ch/ungleich-public/ungleich-staticcms
This commit is contained in:
commit
f55f864798
1 changed files with 106 additions and 0 deletions
106
content/u/blog/no-ipv6-in-2021-not-acceptable/contents.lr
Normal file
106
content/u/blog/no-ipv6-in-2021-not-acceptable/contents.lr
Normal file
|
@ -0,0 +1,106 @@
|
||||||
|
title: No IPv6 in 2021? Not acceptable.
|
||||||
|
---
|
||||||
|
pub_date: 2021-01-09
|
||||||
|
---
|
||||||
|
author: Nico Schottelius
|
||||||
|
---
|
||||||
|
twitter_handle: NicoSchottelius
|
||||||
|
---
|
||||||
|
_hidden: no
|
||||||
|
---
|
||||||
|
_discoverable: yes
|
||||||
|
---
|
||||||
|
abstract:
|
||||||
|
Time is over for legacy-only-IP services.
|
||||||
|
---
|
||||||
|
body:
|
||||||
|
|
||||||
|
It's 2021 and it's time to stop using legacy IP (IPv4) only
|
||||||
|
services. In 2020 we have already seen quite a rise in IPv6
|
||||||
|
connectivity, as well as more and more services emerging IPv6 only.
|
||||||
|
|
||||||
|
## The IPv6 community is very active
|
||||||
|
|
||||||
|
The IPv6 community has reported many bugs to products like
|
||||||
|
[Steam from
|
||||||
|
Valve](https://github.com/ValveSoftware/steam-for-linux/issues/3372),
|
||||||
|
[Dockerhub](https://github.com/docker/roadmap/issues/89) and so many
|
||||||
|
more that it was not possible for me to list them all in this article.
|
||||||
|
|
||||||
|
As a matter of fact, websites or services that have degraded or
|
||||||
|
non-existing IPv6 connectivity [are reported daily on
|
||||||
|
Twitter](https://twitter.com/search?q=%23ipv6).
|
||||||
|
|
||||||
|
## Time to move on
|
||||||
|
|
||||||
|
As I can see it from the work at ungleich, 2020 was a very active year
|
||||||
|
when it comes to IPv6. But at some point, services that don't work
|
||||||
|
with IPv6 are simply not worth caring about anymore.
|
||||||
|
|
||||||
|
While IPv6 [has been defined in
|
||||||
|
1998](https://tools.ietf.org/html/rfc2460), it is clear that vendors
|
||||||
|
and providers need some time to adapt. But 23 years should have been
|
||||||
|
more than enough to migrate.
|
||||||
|
|
||||||
|
For this reason we want to encourage everyone in 2021 to move on, to
|
||||||
|
cut off the old legacy IP applications, services or hardware.
|
||||||
|
|
||||||
|
## How to move on?
|
||||||
|
|
||||||
|
There are a variety of things everyone of us can do and we have
|
||||||
|
collected some easy to take steps.
|
||||||
|
|
||||||
|
### Setup networks IPv6 only
|
||||||
|
|
||||||
|
For every new network you setup, set it up with IPv6 only. All current
|
||||||
|
mobile phones, tablets and operating systems work in IPv6 only
|
||||||
|
networks.
|
||||||
|
|
||||||
|
### Setup services and applications IPv6 only
|
||||||
|
|
||||||
|
If you are an application developer, I suggest to develop your
|
||||||
|
application with IPv6 first. And if you setup a new service, configure
|
||||||
|
IPv6 first and maybe only.
|
||||||
|
|
||||||
|
It's important to understand that setting up something IPv6 only, does
|
||||||
|
not mean it will be unreachable from the legacy IP Internet. NAT64 is
|
||||||
|
one easy to use technology to solve this problem.
|
||||||
|
|
||||||
|
### Abandon legacy only
|
||||||
|
|
||||||
|
Whether it's network hardware, applications, Internet providers,
|
||||||
|
hosting providers - stop using them if they don't work in IPv6 only
|
||||||
|
environments. And let the everyone know that you did so.
|
||||||
|
|
||||||
|
While I am not a fan of shaming anyone, it is still important to let
|
||||||
|
vendors know that you have moved on because of the lack of
|
||||||
|
IPv6. Otherwise the vendor does not know why they are losing
|
||||||
|
customers. When you communicate that you abandon a product or service
|
||||||
|
because of lacking proper IPv6 support, I recommend to doing so in a
|
||||||
|
clear, but respectful way.
|
||||||
|
|
||||||
|
### Advocate IPv6 only
|
||||||
|
|
||||||
|
To be able to spot bugs and to make life for network operators easier,
|
||||||
|
I strongly recommend going IPv6 only. Not dualstack, but simply IPv6
|
||||||
|
only. If you deploy NAT64 in IPv6 only networks, you can even create
|
||||||
|
reachability in both directions.
|
||||||
|
|
||||||
|
Many of us network operators, developers and sysadmins are very good
|
||||||
|
in implementing things. However, it is important to share the word.
|
||||||
|
|
||||||
|
### Help each other
|
||||||
|
|
||||||
|
For about 2 years there is an open, community driven [IPv6
|
||||||
|
Chat](https://ipv6.chat). In this chat you can ask others for help,
|
||||||
|
ask which alternative products or services to use. Or how to migrate
|
||||||
|
to IPv6 only networks. There is also an [IPv6
|
||||||
|
reddit](https://www.reddit.com/r/ipv6/) and an [IPv6 group on
|
||||||
|
Facebook](https://www.facebook.com/groups/2234775539). Many of the
|
||||||
|
RIRs (RIPE, APNIC, Afrinic, LACNIC and ARIN) also offer IPv6 training
|
||||||
|
resources.
|
||||||
|
|
||||||
|
Migrating to IPv6 is not difficult and there is a community to help
|
||||||
|
you with it.
|
||||||
|
|
||||||
|
Let's do it, together.
|
Loading…
Reference in a new issue