<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><br>
</p>
<div class="moz-cite-prefix">On 12/1/18 6:48 AM, Willy MANGA wrote:<br>
</div>
<blockquote type="cite"
cite="mid:4636b82c-c836-2980-ebf0-9c775bb59ea4@gmail.com">
<pre class="moz-quote-pre" wrap="">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. <a class="moz-txt-link-freetext" href="https://lists.afrinic.net/pipermail/rpd/2018/008662.html">https://lists.afrinic.net/pipermail/rpd/2018/008662.html</a></pre>
</blockquote>
<p>I did reply there, and agree this is the better place to discuss.
</p>
<blockquote type="cite"
cite="mid:4636b82c-c836-2980-ebf0-9c775bb59ea4@gmail.com">
<pre class="moz-quote-pre" wrap="">
Le 01/12/2018 à 07:16, Andrew Alston a écrit :
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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</pre>
</blockquote>
</blockquote>
<p>Have to go through the hardware line by line.<br>
</p>
<p>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.</p>
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.
<p>The exception might be CPE; see below.<br>
</p>
<blockquote type="cite"
cite="mid:4636b82c-c836-2980-ebf0-9c775bb59ea4@gmail.com">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
2. Vastly inconsistent support for transition mechanisms and chronically bad support for most of these transition mechanisms in CPE’s</pre>
</blockquote>
</blockquote>
<p>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.<br>
</p>
<p>A few things contribute to this problem: <br>
</p>
<ol>
<li>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.</li>
<li>ISPs buying cheap boxes and not paying anything for support,
so they can't get upgrades.</li>
<li>Foreign ISPs dumping volumes of used CPE, which get resold at
deep discounts. <br>
</li>
</ol>
<p>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.<br>
</p>
<p>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. <br>
</p>
<p>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.<br>
</p>
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. <br>
<p><br>
</p>
<blockquote type="cite"
cite="mid:4636b82c-c836-2980-ebf0-9c775bb59ea4@gmail.com">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
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)</pre>
</blockquote>
</blockquote>
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. <br>
<blockquote type="cite"
cite="mid:4636b82c-c836-2980-ebf0-9c775bb59ea4@gmail.com">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
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.</pre>
</blockquote>
</blockquote>
<br>
<p>Well, bad implementations are bad, and I don't know what to do
about that. Test and file bugs.<br>
</p>
<p>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.<br>
</p>
Security best practices are still best practices.
<blockquote type="cite"
cite="mid:4636b82c-c836-2980-ebf0-9c775bb59ea4@gmail.com">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
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</pre>
</blockquote>
</blockquote>
<p>Should we have a round table discussion at AIS? How can we
identify and make progress on resolving issues with IPv6?<br>
</p>
<p> 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:</p>
<p>1. Write an address plan. Don't worry if it takes several
revisions, that's normal.</p>
<p>2. Apply to Afrinic for IPv6 addresses.</p>
<p>3. Announce the IPv6 addresses and route them on your backbone.</p>
<p>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. </p>
Lee<br>
</body>
</html>