nanog mailing list archives

Re: IPv6 Pain Experiment


From: Doug Barton <dougb () dougbarton us>
Date: Thu, 3 Oct 2019 21:38:18 -0700

I'm going to reply in some detail to your points here because they are
very common arguments that have real answers. Those who have heard all this before are free to move on. :)

You sound like someone who doesn't have experience with IPv6. I don't intend any criticism, I'm simply saying that once you start working with it, you learn it, and almost all of these concerns evaporate. Just like what happened when you learned IPv4.

On 10/3/19 8:20 AM, Naslund, Steve wrote:
I don’t think the issue is the readability of the addresses (although
hex does confuse some people), mainly it is the length and ability to
deal with any string of numbers that long for a human,

Coming from IPv4 world, it's very common that when you're working with addresses directly most or even sometimes all, of the bits are different. By and large this isn't the case with IPv6. If you sized your RIR request properly, you'll have the same /32 (or shorter) prefix across your entire network. That covers the first two hextets of the network portion of the address (that is, half the network portion).

One of the great things about IPv6 is sparse allocation. The next hextet (third of four in the network section of the address) are the bits from /33 through /48. Since except for all but the largest sites you'll assign a /48 per site (65,536 /64s) that hextet will be the same across the entire site. For a really large office site, or a medium size data center, you might assign a /44 (1,048,576 /64s), so 3/4 of that hextet will be stable across that site. For a large data center you might assign a /40 (16,777,216 /64s) so half the hextet will be stable across that site.

So let's say a site is allocated 2001:0db8:1234::/48. A common practice is to use the top of the space for infrastructure, so 2001:0db8:1234:0/49 (32,768 /64s) would be the same prefix used everywhere at that site, and every site would have the same admin prefix. Hopefully by now you can see the opportunities ...

and I do
realize that you can do static addressing in IPv6 (but I sure would
not want to since the manual entry of the addresses is going to be
error prone on both the host and into DNS).

Copy and paste is your friend. Seriously. If you're typing things in you're doing it wrong. Obviously there are a very few situations where you don't have a choice, but seriously, copy and paste. :)

It is just way harder
for a human to deal with hex v6 address than to easily memorize four
decimal numbers in v4.  Most system admins and engineers can rattle
off the IPv4 address of a lot of their systems like gateways, DNS
servers, domain controllers, etc.  Can you imagine keeping those v6
addresses in your head the same way?

Why would you bother? That's what DNS is for. Also, see above, where you can establish patterns that make this easier for the very few situations where you actually have to use addresses, and also easier to spot check them when you do.

Think about reading them over
the phone, typing them into a support case, typing a configuration
sheet to be entered by some remote hands etc.  I am not saying it is
insurmountable, it is just something people need to get used to.  To
me, that is the biggest reason not to do more manual assignments than
we need to. I do understand why they need to be the way they are but
I can't see anyone thinking IPv6 addresses are easier to read and
handle.

No one said easier. Just different. And not hard to learn as you work with them over time.

It is not a misconception that most server guys are used to static
addressing and not auto-assignment.

See the other messages where we talked about how static addressing for services is not a problem for IPv6.

I also takes some time to get
people to stop hardcoding static addressing into system
configurations.  There are lots of applications that have dialog
boxes asking for addresses instead of names.  That needs to stop in
an auto-configured or DHCP environment

Yes, things are different ... one could even argue better, but yes, different.

(yeah, I know all about DHCP reservations but I hate them).

They aren't that bad, but made much easier with a good IPAM. :)

Your comment regarding small networks not needing IPv6 is exactly my
point.  The original post was talking about MANDATING the use of IPv6
to the exclusion of (or taxation of) IPv4.  My point is that there is
not really a need to do so in a lot of use cases.

Is there a huge advantage to stop using RFC1918
addressing within our network?  No, not really.

You've obviously never had to renumber two large internal networks after a merger.

Would I build a
completely new enterprise on IPv4...probably not.   Would I recommend
that every global enterprise eradicate the use of IPv4 in the next
couple of years....no.

No serious person is doing that.

hope this helps,

Doug


Current thread: