[rpd] Summary of proposals: IPv4 Runout Management

[Owen DeLong]

> > * If its common practise to simply announce one's IPv6 on the boarder
> > router and leave IPv6 deployment to that step - which seems quite a
> > simple exercise (you use the word "easy") - then anyone who has a block
> > and has not done at least this and has had their block for 12+ month
> > really needs an official reprimand.
> >
> 
> Not so fast. We have less motivated  net engineers out there who are not motivated at the moment to do it.
> 
> That IPv4 protocol is still kicking and flying and yeah they can still NAT and get things rolling fast.
> 
> Dont forget almost all the Telecoms in this continent have at least some IPv6 prefix seated with them and yet my 3G/4G smart phone still still gets an RFC1918 address every time I get some data bundle fire-up.
> 
In this case, Noah makes a good point, though not the one I think he intended here…

Indeed, many of those engineers that have only deployed IPv6 as far as their border router likely only deployed real IPv4 that far as well. After that, it’s all ugly NAT entanglement throughout their network.

Perhaps this is just a training issue and they do not realize that there is an easy way to do things without NAT. That NAT actually makes their life harder.

Perhaps they have never known a world without a requirement to NAT things and they just don’t understand how a network should work with end-to-end addressing.

Perhaps Mukong can help these poor unfortunate souls to see the light and then the rate of IPv6 adoption can be accelerated as people learn that it is actually easier to deploy IPv6 than to NAT IPv4.

> > 4 - More interesting to measure would be "are there internal services
> > using the IPv6 addresses" - such as the Reverse DNS entries for the IPv6
> > block itself. Another measurement would be whether the email contact
> > addresses are reachable via IPv6 transport.
> >
> > At least that would be a better start.
> >
> 
> Obviously but not so fast. Those internal services like DNS and WWW seat behind some Firewalls that either dont support IPv6 or doing v6 could result into some buggy scenarios. No one will risk that.
> 
Why would you put your web server or your authoritative DNS server behind a firewall that doesn’t support IPv6? That makes no sense whatsoever.

Support for IPv6 is available in almost every common firewall out there today and has been for years.

Of course, I am left wondering why one would put a firewall in front of servers intended to provide public services in the first place, but I’m weird that way. I run a network with no NAT even on IPv4 and where many of my devices are sufficiently hardened that they are able to live on the internet without a firewall in front of them.
> Secondly, those internal services dont normally need a lot of address space :-). So a single /24 IPv4 could be allocated to some services and couple with some NAT Port fowarding behind some Firewall and all is rossy.  So IPv6 in this case becomes less of a priority.
> 
Only if you have no intent of serving the rest of the world as it progresses.

Even Amazon and Azure have seen the light on this. Really, Noah, do you want to continue arguing so hard to keep AfriNIC behind the rest of the world? What is the benefit?

Owen


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20161111/4860962c/attachment.html>