[AfrIPv6-Discuss] Finding solutions to things that stop people moving to IPv6

[Lee Howard]

On 12/1/18 6:48 AM, Willy MANGA wrote:
> Hi,
> I pick it from rpd list [1] because I do not think it's the right place
> to discuss it ... I'll appreciate if people can express share their
> opinions on points below and eventually share their experiences.
>
> 1. https://lists.afrinic.net/pipermail/rpd/2018/008662.html

I did reply there, and agree this is the better place to discuss.

> Le 01/12/2018 à 07:16, Andrew Alston a écrit :
>> You know,
>> [...]
>> Now let me talk about IPv6 – something I happen to know a fair bit about – particularly in terms of ISP deployments.  Let us be completely honest, IPv6 is necessary – and we all have to get there – it’s not an option – v4 simply doesn’t scale to global needs.  But – instead of these meaningless platitudes about how everyone should go to IPv6 – how about we start openly and honestly talking about the challenges with IPv6 and how we address them – so that we can promote its deployment through proper understanding – and instead of everyone going “lets all move to ipv6” – let’s start finding solutions to some of the things that STOP people moving to IPv6.
>>
>>
>>    1.  Lack of legacy support in a fair ton of hardware – how do we deal with it

Have to go through the hardware line by line.

I haven't encountered a router, switch, load balancer, or firewall made 
in the last ten years that wasn't capable of basic IPv6 functions in 
hardware. Some of the oldest required upgrades to line cards or 
controller cards, but those were available by 2012. And many devices 
even older than 2008 had good IPv6 support.

Some advanced features haven't been available for long (like some of the 
MPLS issues you note below), so they may not be implemented widely or 
well. That's just new technology, and it's significantly helped by the 
network effect, as more people work with it.

The exception might be CPE; see below.

>>    2.  Vastly inconsistent support for transition mechanisms and chronically bad support for most of these transition mechanisms in CPE’s

Yes, this is bad. IPv6 support might exist (but isn't always great), but 
without a transition mechanism, you haven't saved any IPv4 addresses. 
The only options you have without CPE support are NAT44 and NAT64, and 
both are slow and expensive and not great for things like inbound 
communication.

A few things contribute to this problem:

 1. Consumers are unaware of IPv6, so it's not part of their buying
    decision. If something doesn't make consumer buy boxes, vendors
    don't do it. I do not think consumer education about IP is a good idea.
 2. ISPs buying cheap boxes and not paying anything for support, so they
    can't get upgrades.
 3. Foreign ISPs dumping volumes of used CPE, which get resold at deep
    discounts.

Something that has worked for some companies is an "ISP Certified" 
sticker. CPE vendors could apply to an ISP, and pay the costs of 
testing. If the tests complied with the ISP's requirements, which might 
include MAP, lw4o6, or 464xlat support, the vendor is allowed to put a 
sticker on their box saying, "This device certified for use with $ISP." 
There might be a business opportunity for someone who can set up a 
really good CPE testing lab, so ISPs could outsource their testing and 
certification.

Something else that works is for the ISP to provide CPE, and include the 
cost in the monthly fee. Then the ISP may choose only to buy CPE that 
meets its requirements.

It might be possible for a group of ISPs with common requirements to 
form a buying pool, where they had a single requirements document they 
could send to several vendors, and agree to buy all CPE from the vendor 
with the best bid. That way, 20 ISPs who would normally buy 5,000 
devices per year get the buying influence of one buying 100,000 per 
year. I don't know if there are laws against collusion that might 
interfere, but I would imagine that ISPs that don't compete wouldn't 
have that problem. This might also be a business opportunity.

This problem is also helped by the network effect, as more ISPs deploy 
IPv6 and realize most transition mechanisms require CPE support. Then 
CPE vendor hear the same requirements from more and more ISP customers.


>>    3.  The complete *mess* that MPLS support as concerns IPv6 (to this day you cannot do vpnv6 without a v4 underlay, martini is entirely bound to LDP and LDPv6 support is near non-existent, and I’ve yet to see Kompella working entirely without v4 in some form either)
I'm not strong in MPLS. 6PE works, but current implementations do still 
require IPv4 underlay. The protocol work is done, now it's just waiting 
for router vendors to update code.
>>    4.  The security challenges around IPv6 and the bad implementations that create issues here – issues which over the years we have learnt to deal with in IPv4 – Happy to expound on these off list – and no – they have nothing to do with NAT or the lack thereof – because NAT as a security mechanism was the biggest lie ever sold to an industry.

Well, bad implementations are bad, and I don't know what to do about 
that. Test and file bugs.

The only inherent security risks I know of that are specific to IPv6 are 
link-local, where a host might send RAs or NAs, but there are several 
known mitigations for those risks. Someone recently argued to me that a 
router that only populated its neighbor table based on DHCPv6 responses 
would be inherently more secure than an IPv4 network.

Security best practices are still best practices.
>>
>> For years I have been an IPv6 advocate – and I still am – and I’ve actively deployed and run IPv6 in production supplying it to the end user, with multiple percentage point changes in country IPv6 penetration statistics as a result, but I am fast realizing that if we want IPv6 to grow and thrive – it’s time we started being a little more open and honest about the challenges and problems with it – instead of sprouting off that everyone should just move to it.   Let’s acknowledge that IPv6 is critical, we have no option, but it is also deeply flawed, has major problems, and until start dealing with those – we will see deployment continue to stutter

Should we have a round table discussion at AIS? How can we identify and 
make progress on resolving issues with IPv6?

The common theme in my answers above is that more people running IPv6 
provides more weight in solving problems. If everyone would take a 
couple of hours to do three things, we'd have a very broad base of 
common experience to draw from:

1. Write an address plan. Don't worry if it takes several revisions, 
that's normal.

2. Apply to Afrinic for IPv6 addresses.

3. Announce the IPv6 addresses and route them on your backbone.

AFRINIC's training and IPv6 Helpdesk are great resources. I don't know 
of any issues with those steps, and for most networks that really is 
just a few hours' work. From that point, as people deploy IPv6 in their 
data centers, to enable web sites, provisioning and OSS systems, they 
might have common experiences to discuss.

Lee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/afripv6-discuss/attachments/20181205/27614968/attachment.html>