[App_rpt-users] IPV6 and upgrades --was: toy throwing time?

Toussaint OTTAVI t.ottavi at bc-109.com
Wed Sep 14 10:19:44 UTC 2016


Le 14/09/2016 à 09:43, Bryan Fields a écrit :
>
> What if your service provider doesn't give you an IPv4 address?  Many service
> providers only give IPv6 addresses now and use DS-Lite or even nat64.  In most
> cases you do not have the ability to map ports on IPv4.

Here, in Corsica, and in France, all ISPs provide IPv4 addresses. Some 
of them provide IPv6, but only as an option. Implementation is often 
experimental and/or buggy. That's the reason why IPv6 is used only for 
experiments / specific tasks. But mainstream business processes still 
use good old IPv4.

> NAT is evil.

People who say that usually do not understand how to write a NAT rule 
correctly, HI :-) I'm using internal addressing for my networks (ie 
10.0.0.0/8), with only a few IPv4 (or AMPRNet) public addresses. I'm 
using good firewalls as gateway. NAT does the job perfectly, and I'm 
happy with it :-)


>
> Most hams cannot announce a subnet via BGP to their service provider.   The
> IP-IP tunnel gateway all flows via one point in San Diego.  It's useless for VoIP.

For those who can not use BGP, only traffic from AMPRNet to the rest of 
the world (public Internet) is routed via the UCSD gateway. But if 
you've got two endpoints A and B, each one with IP-IP tunnel 
configuration behind a home internet "box", and a ripd daemon running at 
both ends, traffic from A to B is routed directly between the two 
endpoint's WAN addresses, via a direct IP-IP tunnel.

Another approach we are using here for our "TKNet" network is to use 
internal addressing (10.44.x.y), and internal VPN tunnels (OpenVPN) 
between sites. Doing so, we have thousands of IPv4 addresses available. 
The whole network only requires one public IPv4 address (the central VPN 
gateway, where the Asterisk hub is located).


>
> You're doing a disservice for your customers if you do not enable v6 for them.
>   IPv4 run out has made v4 expensive.

I'm selling a "service" to my customers. They just want the things to 
work, and they don't ever know what IPv4 or IPv6 are :-). In our current 
situation, it's easier, and less time-consuming, to do things with IPv4 
than it would be with IPv6. And I think things will remain like that for 
several years...

> Your provider is deficient.  Many are, and the only way to get it fixed is by
> demanding proper IPv6 deployment.

Orange, n° 1 ISP in France, is deficient. I already knew that, HI :-D 
And I've been telling them for years. That's exactly the topic of this 
thread : "Throwing time away" :-)

Moreover, my firewall manufacturer (SonicWALL) does not provide "stable" 
firmwares for IPv6. The only existing IPv6 firmwares are considered as 
"early", which would be the equivalent of a debian "testing". I can list 
dozens of other situations where IPv6 implementations are not considered 
as "finished", and where dual-stack setups generate lots of (still 
unsolved) problems.


>
> It's this Luddite attitude that has got us into the place we're at now in IPv6.

I agree. But I'm over 40. I know I can not change the world :-) I just 
can observe how the world all around me is, and choose the best option 
for me. When IPv6 implementations and deployments will be a little bit 
more "finished", mature and stable, then I'll re-evaluate the 
opportunity to migrate to IPv6. But that's not for now ;-)

> We cannot afford to be left behind once again.

Nobody "leaves" us behind. It's up to us to decide about our future. And 
it's up to us to decide how to employ the reduced amount of free time 
more efficiently.

When I see AMPR network still using IP-IP tunnels with unencrypted plain 
text passwords, I think we have so much things to do !!! For example, 
migrating AMPRNet to an IPv6 equivalent, and throwing away IP-IP crap, 
would be an amazing project for the future !  As IPv6 will still be able 
to carry IPv4, migrating endpoint applications such as Asterisk to IPv6 
does not seem to be a priority for me.

But that's just a personal opinion ;-)







More information about the App_rpt-users mailing list