[rpd] Problems (or not) with IPv6

[Lee Howard]

On 12/1/18 1:16 AM, Andrew Alston wrote:
>
> 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
>
"Legacy support" or "IPv6 support"? I've never seen an internet-capable 
device that wasn't capable of IP. I've seen very few that were IPv6-only.

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.

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

Partly due to consumers being 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.

Also partly due to ISPs buying cheap boxes and not paying anything for 
support, so they can't get upgrades.

Also partly due to 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 was allowed to put a 
sticker on their box saying, "This device certified for use with $ISP."

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 problem is also helped by the network effect, as more ISPs deploy 
IPv6 and realize most transition mechanisms require CPE support.


> 1.
>
>
>
>  2. 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)
>
You know this better than I do. 6PE works, from what I understand, but 
it's exactly as you describe, with IPv4 underlaying IPv6. It will be a 
couple of years before good support for native IPv6 MPLS emerges.


> 1.
>
>
>
>  2. 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.

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.

> 1.
>
>
> 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
>
I'd be delighted to participate in such a discussion, as I have here. 
RPD probably isn't the right venue for the discussion. Is there a better 
list (AfriIPv6-Discuss)? Should we have a round table discussion at AIS? 
How can we identify and make progress on resolving issues with IPv6?

It does seem to me that if everyone would take a couple of hours to 
write an address plan and get IPv6 addresses from Afrinic, and take the 
time to route them on their network and announce them, then we'd have a 
lot of organizations starting from a baseline of experience. I don't 
know of any issues with those steps. Then as people deployed IPv6 in 
their data centers, to enable web sites, provisioning and OSS systems, 
they might have common experiences to discuss.


> Andrew
>

Lee


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