IPv6 - real vs theoretical problems

Mailman List Mirror (Read Only)
1

Please, before you flame out, recognize I know a bit of what I am talking about. You can verify this by doing a search on NANOG archives. My point is to actually engage in an operational discussion on this and not insult (or be insulted).

While I understand the theoretical advantages of /64s and /56s and /48s for all kinds of purposes, *TODAY* there are very few folks that are actually using any of them. No typical customer knows what do to do (for the most part) with their own /48, and other than autoconfiguration, there is no particular advantage to a /64 block for a single server -- yet. The left side of the prefix I think people and routers are reasonably comfortable with, it's the "host" side that presents the most challenge.

My interest is principally in servers and high availability equipment (routers, etc) and other things that live in POPs and datacenters, so autoconfiguration doesn't even remotely appeal to me for anything. In a datacenter, many of these concerns about having routers fall over exist (high bandwidth links, high power equipment trying to do as many things as it can, etc).

Wouldn't a number of problems go away if we just, for now, follow the IPv4 lessons/practices like allocating the number of addresses a customer needs --- say /122s or /120s that current router architectures know how to handle -- to these boxes/interfaces today, while just reserving /64 or /56 spaces for each of them for whenever the magic day comes along where they can be used safely?

As far as I can tell, this "crippling" of the address space is completely reversible, it's a reasonable step forward and the only "operational" loss is you can't do all the address jumping and obfuscation people like to talk about... which I'm not sure is a loss.

In your enterprise, behind your firewall, whatever, where you want autoconfig to work, and have some way of dealing with all of the dead space, more power to you. But operationally, is *anything* gained today by giving every host a /64 to screw around in that isn't accomplished by a /120 or so?

Thanks,

DJ

2

Today, I still like SLAAC. All my servers support specifying tokens for the host portion of the prefix. Pre-config, many utilize traditional SLAAC and end up in a range which is stateful firewall protected by the routers until such time as I can renumber them into the appropriate range.

Anyways, ARIN just approved my new allocation and I have to go renumber all those servers. At least assigning the new IPv6 addresses only requires a quick router edit. Application changes will take longer, of course, since we don't automatically generate DNS and other nifties.

The helpdesk, home, and customer trial networks should hopefully renumber with easy per my last renumbering trial. Link addressing, loopback changes, BGP, etc in the routers will still be a PITA.

Jack

3

Hi Deepak,

I acknowledge and see the point made. There is a lot of dead space in the
IPv6 world. Are we allowing history to repeat it self? Well i'm swaying more
to no.

Have you read this RFC? This is pretty satisfying in making me feel more
comfortable assigning out /48 and /64's. I can sleep at night now! :stuck_out_tongue:

http://tools.ietf.org/html//rfc3177

Cheers,
Grant Phillips

4

I largely agree with you, but my knowledge is similar to yours, and
does not extend to dealing with low-end CPE, dormitory LANs, hot
spots, or mobile networks. I am by no means an authority in those
areas and I remain open to the possibility that there may be some
operational advantages to the IPv6 addressing concept for those users.
The problem is there are very serious operational disadvantages for
you and I, but the standard tells us to do it anyway. I would like
the hot spot or mobile guys to be able to choose /64 if they want to.
I need to choose otherwise, and customers expecting /64 as the
"standard" are going to be disappointed until the standard allows for
different choices.

I don't have an opinion on whether the address space is truly
"crippled." If I did, I'm not sure it would be useful. Classful
addressing ran out of gas in IPv4, so IPv6 has a huge number of bits
to hopefully avoid a repeat of that. Okay, I can buy into that.
There are some major networks who aren't, though, and I think they
made a very conscious choice. We won't know if it's a necessary
choice for a long time.

I will choose to devote my arguing-on-the-mailing-list time to topics
I think are more useful to discuss. I do not think you will change
very many minds about IPv6 numbering schemes. I hope I will change
some minds about the current safety of public /64 LANs and get more
folks talking to their vendors about it, which should give us some
kind of solution sooner, rather than later. Choose your battles.

5

Trying to run the IPv6 network using IPv4 addressing practices is
similar to upgrading your horse and buggy
to a sports car, and insisting on driving this car only on dirt roads,
avoiding pavements at all costs, due to the danger
of slipping, if that was the lesson you learned with
horses and buggies.

You can probably do it, and survive, but that does not mean it will
be advantageous trouble free, advisable, or fun.

In this case, you will bring all the negatives (and more) that the
practice had with IPv4, for questionable or no advantages.

It is advisable to look for much stronger reasons than "With
IPv4 we did it" or With IPv4 we ran into such and such
problem" due to unique characteristics of IPv4 addressing
or other IPv4 conventions that had to continue to exist for
compatibility reasons, etc, etc.

6

Please, before you flame out, recognize I know a bit of what I am talking about. You can verify this by doing a search on NANOG archives. My point is to actually engage in an operational discussion on this and not insult (or be insulted).

While I understand the theoretical advantages of /64s and /56s and /48s for all kinds of purposes, *TODAY* there are very few folks that are actually using any of them. No typical customer knows what do to do (for the most part) with their own /48, and other than autoconfiguration, there is no particular advantage to a /64 block for a single server -- yet. The left side of the prefix I think people and routers are reasonably comfortable with, it's the "host" side that presents the most challenge.

My interest is principally in servers and high availability equipment (routers, etc) and other things that live in POPs and datacenters, so autoconfiguration doesn't even remotely appeal to me for anything. In a datacenter, many of these concerns about having routers fall over exist (high bandwidth links, high power equipment trying to do as many things as it can, etc).

Wouldn't a number of problems go away if we just, for now, follow the IPv4 lessons/practices like allocating the number of addresses a customer needs --- say /122s or /120s that current router architectures know how to handle -- to these boxes/interfaces today, while just reserving /64 or /56 spaces for each of them for whenever the magic day comes along where they can be used safely?

No... A single perceived problem would go away and we would reacquire many many more problems that IPv6 is intended to leave behind.

So far, IPv6 scans have been few and far between. The ones we have seen have been short lived and haven't even scanned a single
network (Perhaps some time in the next 500+ years we will see one that does, but, I have my doubts).

I think that targeted or hinted scanning will be the more likely approach in the IPv6 world. We haven't yet seen what will happen in that
realm.

As to what we lose if we eliminate large sparse end networks, we lose the following advantages:

+ Ability to just add machines to a network without having to worry about resizing the network or
  renumbering everything or worst of all adding yet another prefix to hold the new machines.

+ Sparse address density and privacy addressing capabilities

+ SLAAC

+ Simplified "network of things" capabilities

There are probably other things as well, but, those 4 are what I can think of off the top of my head.

Only the first one applies to server environments, but, it's a HUGE win for server environments, so, I think it's worth preserving for
that reason alone. However, if you're willing to abandon that for your server farm, then, nobody is stopping you, actually. IPv6
fully supports statically configured networks of any size down to /127. Knock yourself out.

As far as I can tell, this "crippling" of the address space is completely reversible, it's a reasonable step forward and the only "operational" loss is you can't do all the address jumping and obfuscation people like to talk about... which I'm not sure is a loss.

I'm not sure what you mean by "crippling" of the address space. It seems to be working just fine in a number of production
environments around the world, including both my work and home environments.

In your enterprise, behind your firewall, whatever, where you want autoconfig to work, and have some way of dealing with all of the dead space, more power to you. But operationally, is *anything* gained today by giving every host a /64 to screw around in that isn't accomplished by a /120 or so?

I don't imagine anyone will give every host a /64. What is currently proposed is giving every network a /64. Most networks
contain at least two hosts to be minimally useful (router + end system), and the vast majority of those contain more than
one end system (3+ hosts).

Owen

7

I certainly agree that there are many advantages to the greater
address space offered by IPv6. I don't mean to advocate that we do
things the same way as was necessary to conserve v4 address space, and
I'm sure we all realize that RIR policies necessarily contributed to
routing table growth in trade for extending the life of the available
address space.

I'm not blindly deploying /64 networks, either. Doing so with the
current set of problems, and lack of knobs, is very foolish. My
transit providers offer a mix of /126 and /124 demarc subnets so far,
and /124 is what I choose to standardize on for my BGP customers and
private peering, for simplicity and convenience. As I mentioned
before, I currently allocate a /64 and configure a /124, so I am not
painting myself into a corner either way.

How many of us with an appreciable level of expertise remain concerned
that our approach may need significant adjustment? How many think we
know what those potential adjustments may be, and have planned to make
them easy (or transparent) for ourselves and customers if they become
necessary? This is what is IMO most important to a responsible IPv6
deployment. To do otherwise is inviting unpredictable future pain.

I am comforted by the fact that Level3 is deploying customer demarc
subnets as /126 and is NOT allocating a /64 for each, but are instead
packing them densely in an IPv4 /30 fashion. They recognize problems
with the /64 approach, choose not to follow the "standard" to the
letter, and implement their dual-stack network in a way they
presumably believe is safe and scalable. Large networks like Level3
choosing to insist that equipment vendors support this configuration,
rather than have problems with densely packed subnets smaller than
/64, will mean that anyone who wants to sell a router to Level3 had
better make it work correctly this way, which is good for the small
guy like me who thinks he will eventually transition to that
configuration. Right now, I am still hedging my bet.

Are there any large transit networks doing /64 on point-to-point
networks to BGP customers? Who are they? What steps have they taken
to eliminate problems, if any?

8

Hi Deepak,

No. IPv6 is only *almost* the same as IPv4. Drill these three
differences into your mind and you should do just fine:

/64 LAN netmask
nibble delegation boundary
how many LANs (not hosts!) in this stub network?

Without going into the technical details, IPv6 has been engineered
with the intention that any netmask will work but a /64 netmask works
distinctly better. Don't think of it as a 128 bit address. Think of it
as a 64 bit network address plus a 64 bit host address. Apply IPv4
lessons to the 64 bit network address. The 64 bit host address is for
the customer, the same way the 16-bit TCP port is for the customer.

IPv6 has been rigged so that address space naturally delegates on
nibble boundaries. It's one NS entry in the RDNS zone. It's an exact
string of characters in the hexadecimal written form. Should you
delegate on a different boundary, you invite all the common
difficulties human beings have evaluating a netmask and add in the
trouble dealing with base 16, rarely for any discernible gain.

In IPv4 you think about how many addresses do I need to accommodate X
hosts. This mental model does not match IPv6's technology model. If
LANs are always /64, how many LANs does this stub network require?

Example: Customer A has a gaming PC in a DMZ and two surfing PCs. How
many IPv6 addresses?

1 LAN (/64) for the DMZ
1 LAN (/64) for the PCs
1 LAN (/64) between the firewall and the router
round up to the nibble boundary: 16 LANs (/60)

Consider providing a /56 or a /48 instead of a /60 so that there's
lots of room for expansion, dynamic interior delegation or whatever.
But /60 is your absolute floor. Less will turn out to be like telling
the same customer to use 192.168.1.252/30: technical difficulties will
promptly ensue.

Regards,
Bill Herrin

9

I can't tell if you're trolling, or if you didn't get the memo from Monday. I guess I'll lean toward the latter.

http://www.ietf.org/mail-archive/web/v6ops/current/msg06820.html

      Jima

10

That's a draft, and, it doesn't really eliminate the idea that /48s are generally
a good thing so much as it recognizes that there might be SOME circumstances
in which they are either not necessary or insufficient.

As a draft, it hasn't been through the full process and shouldn't be considered
to have the same weight as an RFC.

While it intends to obsolete RFC-3177, it doesn't obsolete it yet and, indeed, may
never do so.

Owen

11

Fully understood; I wasn't meaning to present it as irrefutable evidence that the /64 & /48 mindset is flawed, but as a timely counterpoint to people expounding the virtues of 3177 without cautiously acknowledging that its recommendations aren't necessarily for everyone. I apologize if my intentions weren't terribly clear -- that may be a good cue for me to go to bed.

      Jima

12

I believe that the draft, even if it were to be adopted as is, does not intend to obsolete the /64, just the /48
recommendation in 3177.

Owen

13

Are there any large transit networks doing /64 on point-to-point
networks to BGP customers? Who are they? What steps have they taken
to eliminate problems, if any?

Our Global Crossing IPv6 transit is on a /64 Ethernet point-to-point.

Steinar Haug, Nethelp consulting, sthaug@nethelp.no

14

The IETF data tracker shows draft-ietf-v6ops-3177bis-end-sites is under IESG review, with comments currently being made, see
https://datatracker.ietf.org/doc/draft-ietf-v6ops-3177bis-end-sites/
which also notes the draft has strong support so is likely to be published soon.

The document is only guidance regardless.

Tim

15

Our Qwest and TW Telecom links are /64.

16

Add HE.net to the list.

-Randy
www.fastserv.com

17

Thanks Grant, I've already read this. :slight_smile:

I have no problem with enabling /64s for everyone/everything in the future, as the equipment capability increases, but right now there are real concerns about en masse deployment and the vulnerabilities we open our hardware to.

Which is why I was talking about reserving the larger block, but only allowing folks to have as much space as they can manage successfully and with a similar risk profile as they have today. Obviously it doesn't take too many people leaving their networks wide to cause a problem for the rest of us.

Best,

Deepak

18

> http://www.ietf.org/mail-archive/web/v6ops/current/msg06820.html
>
> Jima

Just skimming through the draft:

     1) It is no longer recommended that /128s be given out. While there
        may be some cases where assigning only a single address may be
        justified, a site by definition implies multiple subnets and
        multiple devices.

--- I never knew a site, by definition, has multiple subnets and devices.

   A key principle for address management is that end sites always
        be able to obtain a reasonable amount of address space for their
        actual and planned usage, and over time ranges specified in
        years rather than just months. In practice, that means at least
        one /64, and in most cases significantly more. One particular
        situation that must be avoided is having an end site feel
        compelled to use IPv6-to-IPv6 Network Address Translation or
        other burdensome address conservation techniques because it
        could not get sufficient address space.

I think this is the real point everyone is trying to get at. They want IP6 to be the end of NAT. Got it. There are now years of security dogma that says NAT is a good thing, in the 20+ years IP6 has been on the books, the dogma went another way. This concept will take a long time to unwind. Somehow this is supposed to mesh with dynamic renumbering where we can move around between /48s without "too much burden" while wildly waving our hands at all the higher-level configs (DNS, Applications, firewalls, etc) that don't play nicely with automatic renumbering.

There is some convoluted discussion about how they wanted their /48 policy to somehow encourage residential ISPs to give their users more IP space in the base offering. I'm not sure why or what purpose an addressing policy should have to a business case. I see nothing motivating a residential ISP (especially one providing CPE equipment) to change their current deployment system one iota. And I'm pretty sure they are the ones MOST exposed to abuses of this address space by the least technical user base. (side note, if I were a residential ISP I'd configure a /64 to my highly-controlled CPE router and issue /128s to each and every device that plugged in on the customer site, and only one per MAC and have a remotely configurable limit of say 50 devices or whatever the mac table limit was. So I only have one route entry in my aggregation layer and if the customer blows his CPE router up, I'm still protected.)

Question - Whatever happened to the concept of a customer coming to their SP for more space? Why do we have to give them enough space for a decade of theoretical use when every week we could widen their subnet without causing any negative impact on them? No renumbering, etc. It's not considered a burden today, but under IP6 it is? Heck, since space is so plentiful, we can all set up gateways to do it automatically, but until routers get smarter, I don't see how all that dead routable space is a good thing. Customers are paying for and getting a service, a continuous relationship with some set of SPs. In that service they aren't getting a mathematical representation, they are getting usable IP space, but that doesn't mean that if they hop out of bed in the middle of the night and decide to allocate 5,000,000 unique IPs the SP network should automatically accept it (based on today's current technology).

BOGONS, IP hijacks and all the rest seem like the worse problem here and the whole point of putting training wheels on these roll outs. Instead, it seems we are systematically unwinding all the lessons learned from CIDR and going back to addresses being classful, interface links being massive space wasters and no one caring about addresses. That's fine, and probably an improvement, until the next round of attacks and then shortages occur. Once the schools start teaching RFC3177, the hardcoded apps are sure to follow.

Deepak

19

least technical user base. (side note, if I were a residential ISP I'd configure a /64 to my highly-controlled CPE router and issue /128s to each and every device that plugged in on the customer site, and only one per MAC and have a remotely configurable limit of say 50 devices or whatever the mac table limit was. So I only have one route entry in my aggregation layer and if the customer blows his CPE router up, I'm still protected.)

This is exactly the reason to issue /48 or /56 to the end user. You give them plenty of space, and you then don't have to care anymore about what the user does with this space. You keep do LL only between CPE and PE, so you only need to keep 4 TCAM entries per customer (one for the /XX route, one for the LL adjacancy, one for the permit ACL to permit packets from the /XX, and one deny line. (I might be misunderstanding exactly what's needed here and a few TCAM entries more are needed, but you get the idea).

until routers get smarter, I don't see how all that dead routable space is a good thing. Customers are paying for and getting a service, a continuous relationship with some set of SPs. In that service they

If I give them a /56 then it's zero administration for me for the forseeable future. Why on earth would I want to handle customer administration when I don't need to?

20

Clever folks figured that making the customer wait for support hours
and then paying people to process configuration changes could be
usefully removed from the business cycle?

Regards,
Bill Herrin