Re: 128 bits should be enough for everyone, was: IPv6 vs. Stupid NAT tricks: false dichotomy? (Was: Re: StupidNAT tricks and how to stop them.)
On 31-mrt-2006, at 6:11, Steven M. Bellovin wrote: You're absolutely right about the /3 business -- this was a very deliberate design decision. So, by the way, was the decision to use 128-bit, fixed-length addresses -- we really did think about this stuff, way back when. I reviewed some old IPng mail archives last year and it was very illuminating to see people worry both about stuff that is completely a non-issue today and stuff that's still as big a problem as ever today. However, a lot has changed in over a decade, and even if fixed length addresses was the right answer then (which I'm not necessarily conceding), that doesn't necessarily make it the right answer today. When the IPng directorate was designing/selecting what's now IPv6, there was a variable-length address candidate on the table: CLNP. I'm no OSI expert, but what I gather is that within a domain, all addresses must be the same length, so variable length addressing doesn't really work out in practice. It was strongly favored by some because of the flexibility; others pointed out how slow that would be, especially in hardware. I guess that argument can be made for the traditional this address is X bits and here are enough bytes to hold them type of variable length address encoding that we also use in BGP, for example. But there are other ways to do this that are more hardware-friendly: There was another proposal, one that was almost adopted, for something very much like today's IPv6 but with 64/128/192/256-bit addresses, controlled by the high-order two bits. That looked fast enough in hardware, albeit with the the destination address coming first in the packet. OTOH, that would have slowed down source address checking (think BCP 38), so maybe it wasn't a great idea. On the other hand having a protocol chain in IPv6 makes checking TCP/ UDP ports a nightmare, so there's more than enough precedent for that. That's one lesson we can learn from the OSI guys: the port number should really be part of the address. A way to encode variable length addresses that would presumably be even easier to implement in hardware is to split the address in several fields, and then have some bits that indicate the presence/ absence of these fields. For instance, the IPv6 address could be 8 16- bit values. The address 3ffe:2500:0:310::1 would be transformed into 3ffe-2500-0310-0001 (64 bits) with the control bits 11010001 indicating that the first, second, fourth and eighth 16-bit values are present but the third and fifth - seventh aren't. It should be fairly simple to shift the zero bits in and out in hardware so the full maximum length version of the address can be available in places where that's convenient. And in reaction to other posts: there is no need to make the maximum address length unlimited, just as long as it's pretty big, such as ~256 bits. The point is not to make the longest possible addresses, but to use shorter addresses without shooting ourselves in the foot later when more address space is needed. For instance, I have a /48 at home and one for my colocated server. For that server, I could use the /48 as the actual address for the server, or add a very small number of bits. At home, stateless autoconf is useful so 94 bits would be sufficient (/48 + 46 bit MAC address), maybe add a couple of bits for future subnetting. So the server address would be 7 bytes (with the length field) rather than 16 and the laptop address 13, saving 12 bytes per packet between the two over today's IPv6... I'm carefully not saying which option I supported. I now think, though, that 128 bits has worked well. It would be rather disastrous if 128 bits didn't work well at this stage. :-) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: 128 bits should be enough for everyone, was: IPv6 vs. Stupid NAT tricks: false dichotomy? (Was: Re: StupidNAT tricks and how to stop them.)
Iljitsch van Beijnum writes: And in reaction to other posts: there is no need to make the maximum address length unlimited, just as long as it's pretty big, such as ~256 bits. But there isn't much reason to not make it unlimited, as the overhead is very small, and specific implementations can still limit the actual address length to a compromise between infinity and the real-world network that the implementation is expected to support. The point is not to make the longest possible addresses, but to use shorter addresses without shooting ourselves in the foot later when more address space is needed. Use unlimited-length addresses that can expand at _either_ end, and the problem is solved. When more addresses are needed in one location, you add bits to the addresses on the right; when networks are combined and must have unique addresses, you add bits on the left. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: 128 bits should be enough for everyone, was: IPv6 vs. Stupid NAT tricks: false dichotomy? (Was: Re: StupidNAT tricks and how to stop them.)
Thus spake Anthony G. Atkielski [EMAIL PROTECTED] Iljitsch van Beijnum writes: However, since that time I've learned to appreciate stateless autoconfiguration and the potential usefulness of having the lower 64 bits of the IPv6 address as a place to carry some limited security information (see SEND and shim6 HBA). Once it's carrying information, it's no longer just an address, so counting it as pure address space is dangerous. An IPv4/6 address is both a routing locator and an interface identifier. Unfortunately, the v6 architects decided not to separate these into separate address spaces, so an address _must_ contain routing information until that problem is fixed. It doesn't seem to be likely we'll do so without having to replace IPv6 and/or BGP4+, and there's no motion on either front, so we're stuck with the locator/identifier problem for quite a while. Building in space means not allocating it--not even _planning_ to allocate it. Nobody has any idea what the Internet might be like a hundred years from now, so why are so many people hellbent on planning for something they can't even imagine? That's why 85% of the address space is reserved. The /3 we are using (and even then only a tiny fraction thereof) will last a long, long time even with the most pessimistic projections. If it turns out we're still wrong about that, we can come up with a different policy for the next /3 we use. Or we could change the policy for the existing /3(s) to avoid needing to consume new ones. If IPv6 is supposed to last 100 years, that means we have ~12.5 years to burn through each /3, most likely using progressively stricter policies. It's been a decade since we started and we're nowhere near using up the first /3 yet, so it appears we're in no danger at this point. Will we be in 50 years? None of us know, which is why we've reserved space for the folks running the Internet then to make use of -- provided IPv6 hasn't been replaced by then and making this whole debate moot. Unfortunately, at the time IPv6 was created variable length addresses weren't considered viable. Variable-length addresses are the only permanent solution, unless IP addresses are assigned serially (meaning that all routing information has to be removed). Variable-length addresses work very well for the telephone system, and they'd work just as well for the Internet, if only someone had taken the time to work it out. Variable-length addresses only work if there is no maximum length. E.164 has a maximum of 15 digits, meaning there are at most 10^15 numbers. Here in +1 we only use eleven digit numbers, meaning we're burning them 10^4 times as fast as we could. That's not a great endorsement. Also, telephone numbers have the same locator/identifier problem that IPv4/6 addresses do. In fact, IPv6's original addressing model looked strikingly similar to the country codes and area/city codes (aka TLAs and NLAs) that you're apparently fond of. Even OSI's variable length addresses had a maximum length, and most deployments used the maximum length; they degenerated into fixed-length addresses almost immediately. The only thing I'm not too happy about is the current one address / one subnet / /48 trichotomy. Ignoring the single address for a moment, the choice between one subnet and 65536 isn't a great one, as many things require a number of subnets that's greater than one, but not by much. It's a good example of waste that results from short-sightedness. It happened in IPv4, too. The difference is that in IPv6, it's merely a convention and implementors are explicitly told that they must not assume the above boundaries. In IPv4, it was hardcoded into the protocol and every implementation had to be replaced to move to VLSM and CIDR. Conventions are for human benefit, but they can be dropped when it becomes necessary. Folks who use RFC 1918 space almost always assign /24s for each subnet regardless of the number of hosts; folks using public addresses used to do the same, but instead now determine the minimum subnet that meets their needs. Hopefully the conventions in IPv6 won't be under attack for a long time, but if they need to go one day we can drop them easily enough. The thing that is good about IPv6 is that once you get yourself a / 64, you can subdivide it yourself and still have four billion times the IPv4 address space. It sounds like NAT. Not at all. You'd still have one address per host, you'd just move the subnet boundary over a few bits as needed. With the apparent move to random IIDs, there's no reason to stick to /64s for subnets -- we could go to /96s for subnets without any noticeable problems (including NAT). The RIRs could also change policies so that /32 and /48 are not the default allocation and assignment sizes, respectively. That is also another convention that we could easily dispense with, but it saves us a lot of paperwork to abide by it as
Re: 128 bits should be enough for everyone, was: IPv6 vs. Stupid NAT tricks: false dichotomy? (Was: Re: StupidNAT tricks and how to stop them.)
Thus spake Anthony G. Atkielski [EMAIL PROTECTED] Iljitsch van Beijnum writes: So how big would you like addresses to be, then? It's not how big they are, it's how they are allocated. And they are allocated very poorly, even recklessly, which is why they run out so quickly. It's true that engineers always underestimate required capacity, but 128-bit addresses would be enough for anything ... IF they were fully allocated. But I know they won't be, and so the address space will be exhausted soon enough. I once read that engineers are generally incapable of designing anything that will last (without significant redesign) beyond their lifespan. Consider the original NANP and how it ran out of area codes and exchanges around 40 years after its design -- roughly the same timeframe as the expected death of its designers. Will IPv6 last even that long? IMHO we'll find a reason to replace it long before we run out of addresses, even at the current wasteful allocation rates. We currently have 1/8th of the IPv6 address space set aside for global unicast purposes ... Do you know how many addresses that is? One eighth of 128 bits is a 125-bit address space, or 42,535,295,865,117,307,932,921,825,928,971,026,432 addresses. That's enough to assign 735 IP addresses to every cubic centimetre in the currently observable universe (yes, I calculated it). Am I the only person who sees the absurdity of wasting addresses this way? It doesn't matter how many bits you put in an address, if you assign them this carelessly. That's one way of looking at it. The other is that even with just the currently allocated space, we can have 35,184,372,088,832 sites of 65,536 subnets of 18,446,744,073,709,551,616 hosts. Is this wasteful? Sure. Is it even conceivable to someone alive today how we could possibly run out of addresses? No. Will someone 25 years from now reach the same conclusion? Perhaps, perhaps not. That's why we're leaving the majority of the address space reserve for them to use in light of future requirements. ... with the idea that ISPs give their customers /48 blocks. Thank you for illustrating the classic engineer's mistake. Stop thinking in terms of _bits_, and think in terms of the _actual number of addresses_ available. Of better still, start thinking in terms of the _number of addresses you throw away_ each time you set aside entire bit spans in the address for any predetermined purpose. Remember, trying to encode information in the address (which is what you are doing when you reserve bit spans) results in exponential (read incomprehensibly huge) reductions in the number of available addresses. It's trivially easy to exhaust the entire address space this way. If you want exponential capacity from an address space, you have to assign the addresses consecutively and serially out of that address space. You cannot encode information in the address. You cannot divided the address in a linear way based on the bits it contains and still claim to have the benefits of the exponential number of addresses for which it supposedly provides. Why is this so difficult for people to understand? And sequential assignments become pointless even with 32-bit addresses because our routing infrastructure can't possibly handle the demands of such an allocation policy. The IETF has made the decision to leave the current routing infrastructure in place, and that necessitates a bitwise allocation model. Railing against this decision is pointless unless you have a new routing paradigm ready to deploy that can handle the demands of a non-bitwise allocation model. Why is this so difficult for you to understand? That gives us 45 bits worth of address space to use up. You're doing it again. It's not 45 bits; it's a factor of 35,184,372,088,832. But rest assured, they'll be gone in the blink of an eye if the address space continues to be mismanaged in this way. I take it you mean the blick of an eye to mean a span of decades? That is not the common understanding of the term, yet that's how long we've been using the current system and it shows absolutely no signs of strain. It's generally accepted that an HD ratio of 80% should be reachable without trouble, which means we get to waste 20% of those bits in aggregation hierarchies. No. It's not 20% of the bits, it's 99.9756% of your address space that you are wasting. Do engineers really study math? To achieve bitwise aggregation, you necessarily cannot achieve better than 50% use on each delegation boundary. There are currently three boundaries (RIR, LIR, site), so better than 12.5% address usage is a lofty goal. Again, if you want something better than this, you need to come up with a better routing model than what we have today. (And then throw in the /64 per subnet and you're effectively wasting 100% of the address space anyways, so none of this matters until that's gone) This gives us 36 bits = 68
Re: 128 bits should be enough for everyone, was: IPv6 vs. Stupid NAT tricks: false dichotomy? (Was: Re: StupidNAT tricks and how to stop them.)
On Thu, 30 Mar 2006 20:43:14 -0600, Stephen Sprunk [EMAIL PROTECTED] wrote: That's why 85% of the address space is reserved. The /3 we are using (and even then only a tiny fraction thereof) will last a long, long time even with the most pessimistic projections. If it turns out we're still wrong about that, we can come up with a different policy for the next /3 we use. Or we could change the policy for the existing /3(s) to avoid needing to consume new ones. I really shouldn't waste my time on this thread; I really do know better. You're absolutely right about the /3 business -- this was a very deliberate design decision. So, by the way, was the decision to use 128-bit, fixed-length addresses -- we really did think about this stuff, way back when. When the IPng directorate was designing/selecting what's now IPv6, there was a variable-length address candidate on the table: CLNP. It was strongly favored by some because of the flexibility; others pointed out how slow that would be, especially in hardware. There was another proposal, one that was almost adopted, for something very much like today's IPv6 but with 64/128/192/256-bit addresses, controlled by the high-order two bits. That looked fast enough in hardware, albeit with the the destination address coming first in the packet. OTOH, that would have slowed down source address checking (think BCP 38), so maybe it wasn't a great idea. There was enough opposition to that scheme that a compromise was reached -- those who favored the 64/128/192/256 scheme would accept fixed-length addresses if the length was changed to 128 bits from 64, partially for future-proofing and partially for flexibility in usage. That decision was derided because it seemed to be too much address space to some, space we'd never use. I'm carefully not saying which option I supported. I now think, though, that 128 bits has worked well. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: 128 bits should be enough for everyone, was: IPv6 vs. Stupid NAT tricks: false dichotomy? (Was: Re: StupidNAT tricks and how to stop them.)
Stephen Sprunk writes: An IPv4/6 address is both a routing locator and an interface identifier. And so engineers should stop saying that n bits of addressing provides 2^n addresses, because that is never true if any information is encoded into the address. In fact, as soon as any information is placed into the address itself, the total address space shrinks exponentially. Unfortunately, the v6 architects decided not to separate these into separate address spaces, so an address _must_ contain routing information until that problem is fixed. It doesn't seem to be likely we'll do so without having to replace IPv6 and/or BGP4+, and there's no motion on either front, so we're stuck with the locator/identifier problem for quite a while. Then we need to make predictions for the longevity of the scheme based on the exponentially reduced address space imposed by encoding information into the address. In other words, 128 bits does _not_ provide 2^128 addresses; it does not even come close. Ultimately, it will barely provide anything more than what IPv4 provides, if current trends continue. That's why 85% of the address space is reserved. The /3 we are using (and even then only a tiny fraction thereof) will last a long, long time even with the most pessimistic projections. If it turns out we're still wrong about that, we can come up with a different policy for the next /3 we use. Or we could change the policy for the existing /3(s) to avoid needing to consume new ones. Or simply stop trying to define policies for an unknown future, and thereby avoid all these problems to begin with. It's been a decade since we started and we're nowhere near using up the first /3 yet, so it appears we're in no danger at this point. As soon as you chop off 64 bits for another field, you've lost just under 100% of it. Variable-length addresses only work if there is no maximum length. Ultimately, yes. But there is no reason why a maximum length must be imposed. E.164 has a maximum of 15 digits, meaning there are at most 10^15 numbers. Here in +1 we only use eleven digit numbers, meaning we're burning them 10^4 times as fast as we could. That's not a great endorsement. Telephone engineers make the same mistakes as anyone else; no natural physical law imposes E.164, however. Also, telephone numbers have the same locator/identifier problem that IPv4/6 addresses do. In fact, IPv6's original addressing model looked strikingly similar to the country codes and area/city codes (aka TLAs and NLAs) that you're apparently fond of. Maybe the problem is in trying to make addresses do both. Nobody tries to identify General Electric by its street address, and nobody tries to obtain a street address based on the identifier General Electric alone. The difference is that in IPv6, it's merely a convention ... Conventions cripple society in many cases, so merely a convention may be almost an oxymoron. The folks who designed IPv4 definitely suffered from that problem. The folks who designed IPv6 might also have suffered from it, but at least they were aware of that chance and did their best to mitigate it. Could they have done better? It's always possible to second-guess someone ten years later. There's also plenty of time to fix it if we develop consensus there's a problem. Sometimes the most important design criterion is ignorance. In other words, the best thing an engineer can say to himself in certain aspects of design is I don't know. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
