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
_______________________________________________
AfrIPv6-Discuss mailing list
[email protected]
https://lists.afrinic.net/mailman/listinfo/afripv6-discuss
