17 May
2021
17 May
'21
4:03 a.m.
On 5/16/21 8:33 PM, Antonios Chariton (daknob) via 44Net wrote:
When we deploy IPv6, we get operational experience. We can create guides and write posts
about the problems we ran into, and how we solved them. We can produce valuable knowledge
that applies to everyone. We can give talks about how we overcame certain difficulties, so
people that find themselves in a similar situation in the future do not have to figure it
out themselves as well.
Ok but I *do* use IPv6 on internet, and manage it both on my
home and at work. For a long time already.
And I know well about the problems, e.g. the issues with sites and services that claim to
be on IPv6 (in DNS) but it does not really work.
That has become much less of a problem these days, but up to ~5 years ago it was
relatively common to find a server not working or sending a "Apache is installed
correctly" page when accessed via IPv6 while the same service worked OK with IPv4.
That has caused me helpdesk tickets, and brought me in the situation of "when we
would not have IPv6 we would not have had this issue"...
I think that is also what holds many ISPs back: deploying IPv6 can "only cause new
problems" and it rarely ever brings any new functionality yet.
So they have to weigh the disadvantage of causing a new problem and bad reputation against
the benefit of going with the times.
Apparently many choose to postpone it.
When we constantly bug our vendors (e.g. MikroTik)
about IPv6 and feature-parity and we always request these features, and we use them, and
we report bugs in them, we send a message that this “feature” is important to us (the
users), we need it to consider the product functional, and it has to be tested, working,
and released together (or before) with the IPv4-equivalent. This helps everyone else on
the Internet deploy IPv6, because all their devices now support it easily and reliably,
and it’s there already.
I have been bugging MikroTik for several years now. On the
forum, on their email, and also in personal talks to their personnel at their MUM events.
A couple of years back, I got the reply "well, rarely any of our customers asks us
for IPv6 support" and that may well have been true in their market of pop-and-son
wireless ISPs serving some rural community with low-cost equipment.
At the moment they are less negative about it but their development of RouterOS v7 is in
progress for many years already, and while the current beta (which I download and run in a
VM) has some new features that look promising, they also did a complete rewrite of some
subsystems (like BGP) leaving them in a currently unusable state.
So we cannot test it in real life yet, we have to wait for some more betas to even be able
to beta-test it, and then it might take more time before the test outcome is "we can
migrate some or most routers in our network".
I also have a number of IPv4 and IPv6 addresses and I
receive this traffic as well. I just think it’s normal. It’s part of having public IPv4
addresses. Having 2 Mb/s for a /16 is minimal (given the block size) so I wouldn’t
personally consider it disruptive.
Well we cannot afford to route that over our
network. So we have a firewall at the perimeter that blocks this incoming traffic.
Of course in fact we block ALL incoming traffic unless the user of an IP address has
explicitly requested to allow it, but that could become impossible when we ever get
redundant gateways.
So the generic filtering of this research traffic remains a requirement.
Thanks a lot for the pointers! Very nice, organized,
and I assume also automatically updated
The data is collected in different ways,
some of it is live data (address lists), some additional data is added hourly using
scripts that do SNMP polling etc.
Of course (some people did not understand that) the info is only available to AMPRnet
users.
I do not have any problems with using /24’s for
EchoLink, or anything else, we can clearly “afford to be wasteful” at this size. And maybe
we should be for this instance. I don’t know, really. However, I was merely pointing out
the fact that requiring a single IPv4 *per connection* instead of what the rest of the
Internet does which is a single *port* per connection is indeed a lot.
I am not the
developer of Echolink and I have no influence on their protocol and software decisions.
Echolink uses RTMP/RTCMP and their protocols are not NAT friendly.
They also cannot easily be extended to use IPv6 because IP addresses and port numbers are
embedded in the packets.
Rob