Re: IPv6 addressing limitations (was national security)
Anthony G. Atkielski; I've described variable-length addresses in the past. Essentially a system like that of the telephone network, with addresses that can be extended as required at either end. Such addressing allows unlimited ad hoc extensibility at any time without upsetting any routing already in place. Unlimited? The limitation on public part is 20 digits. Ad hoc extension beyond hardware supported length at that time will fatally hurt performance. Masataka Ohta
Re: IPv6 addressing limitations (was national security)
Dear Masataka, my interest in this is national security. I see a problem with IPv6 in two areas. 1. the 001 numbering plan as inadequate to national interests - digital soverignty, e-territory organization, law enforcement, security and safetey, etc. related reasons (I do not discuss their degree of relevance, just the existance). 2. the Y2K syndrome. IPv6 has 6 potential numbering plan. Launching it in real production without certifying it and the equipment to multiple plan support capacity is unacceptable. When there will be millions on IPv6 inside without large scale testing of multiple numbering plan support, and many ways of use, applciations etc. developed with one single actually used plan in mind, no one will able to seriously propose an additional plan. Comments welcome. jfc At 05:20 04/12/03, Masataka Ohta wrote: Content-Transfer-Encoding: 7bit Iljitsch; We need to keep the size of the global routing table in check, which means wasting a good deal of address space. That's not untrue. However, as the size of the global routing table is limited, we don't need so much number of bits for routing. 61 bits, allowing 4 layers of routing each with 32K entries, is a lot more than enough. Even in IPv4, where addresses are considered at least somewhat scarce, a significant part of all possible addresses is lost because of this. Only 20 bits or so for routing is, certainly, no good. If we want to keep stateless autoconfig and be modestly future-proof we need at least a little over 80 bits. 96 would have been a good number, but I have no idea what the tradeoffs are in using a broken power of two. If we assume at least 96 bits are necessary, IPv6 only wastes 2 x 32 bits = 8 bytes per packet, or about 0,5% of a maximum size packet. Not a huge deal. And there's always header compression. Stateless autoconfig is mostly useless feature applicable only to hosts within a private IP network that 64 bits could have worked. 128 bit is here to enable separation of 64 bit structured ID and 64 bit locator. Masataka Ohta
Re: IPv6 addressing limitations (was national security)
Anthony G. Atkielski; Unlimited? The limitation on public part is 20 digits. That's just a matter of programming these days. On the Internet these days, it is a matter of hardware. Ad hoc extension beyond hardware supported length at that time will fatally hurt performance. What hardware limits numbers to 20 digits today? On psuedo packet network, such as X.25 or ATM, with full of connection, packets are forwarded by hardware with short connection ids where e.164 numbers are used at the time of complex signalling processed by software. Masataka Ohta
Re: IPv6 addressing limitations (was national security)
jfcm; Dear Masataka, my interest in this is national security. I see a problem with IPv6 in two areas. Only two? IPv6 contains a lot of unnecessary features, such as stateless autoconfiguration, and is too complex to be deployable. Comments welcome. As it is too complex, it naturally has a lot of security problems. I'm not surprised some of them are national ones. Masataka Ohta
Re: IPv6 addressing limitations (was national security)
See, that's the classic mistake: Everyone wants to divide the entire address space RIGHT NOW, without any clue as to how the world will evolve in years to come. Nature may abhor a vacuum, but it certainly That not correct. See: http://www.iana.org/assignments/ipv6-address-space Where it says: 2) For now, IANA should limit its allocation of IPv6 unicast address space to the range of addresses that start with binary value 001. The rest of the global unicast address space (approximately 85% of the IPv6 address space) is reserved for future definition and use, and is not to be assigned by IANA at this time. It was well understood that it was important to keep most of the IPv6 address space open to allow for future use. Bob
Re: IPv6 addressing limitations (was national security)
Iljitsch; We need to keep the size of the global routing table in check, which means wasting a good deal of address space. That's not untrue. However, as the size of the global routing table is limited, we don't need so much number of bits for routing. 61 bits, allowing 4 layers of routing each with 32K entries, is a lot more than enough. Even in IPv4, where addresses are considered at least somewhat scarce, a significant part of all possible addresses is lost because of this. Only 20 bits or so for routing is, certainly, no good. If we want to keep stateless autoconfig and be modestly future-proof we need at least a little over 80 bits. 96 would have been a good number, but I have no idea what the tradeoffs are in using a broken power of two. If we assume at least 96 bits are necessary, IPv6 only wastes 2 x 32 bits = 8 bytes per packet, or about 0,5% of a maximum size packet. Not a huge deal. And there's always header compression. Stateless autoconfig is mostly useless feature applicable only to hosts within a private IP network that 64 bits could have worked. 128 bit is here to enable separation of 64 bit structured ID and 64 bit locator. Masataka Ohta
Re: IPv6 addressing limitations (was national security)
Keith Moore writes: This was shortsighted, just like having the notion of class built into IPv4 addresses was shortsighted. Just about everything about address allocation has always been shortsighted. I have a simple idea: Why not just define the first three /32 chunks of the IPv6 address space as three IPv4 spaces, and leave the rest of the IPv6 reserved? This triples the amount of address space available to 12 billion addresses. You put all the existing addresses in the first chunk, and then expand to the second and third chunks as required once IPv6 is widespread. You leave all the rest ALONE until these chunks are exhausted. Simple, no? And it involves no stupid decisions that will cause the entire address space to be exhausted in twenty years. It buys you possibly decades of time in which to think of a new and better way to allocate a bit more address space. You proceed by small increments like this for the future, never attempting to allocate the entire space at once. And if you do it that way, there's a good chance that you'll never run out of space, and rewriting will be minimal or nonexistent. Fortunately the mistake is easily rectified, so long as software doesn't get into the habit of expecting the lower 64 bits of an address to be a unique interface identifier. Why dedicated /64 to anything? We are getting by just fine on /32 for the whole world right now. Why is a sudden expansion of 2^32 required RIGHT NOW? See, that's the classic mistake: Everyone wants to divide the entire address space RIGHT NOW, without any clue as to how the world will evolve in years to come. Nature may abhor a vacuum, but it certainly also seems that engineers abhor unallocated address space, and will try to allocate everything even when they are lightyears off the mark, and even if it means rewriting all the software in the world a few decades later.
Re: IPv6 addressing limitations (was national security)
On 2-dec-03, at 20:42, Schiro, Dan wrote: Fortunately the mistake is easily rectified, so long as software doesn't get into the habit of expecting the lower 64 bits of an address to be a unique interface identifier. This is a dangerous prospect. The company I work for makes a networking stack and our IPv6 implementation expects the lower 64 bits to be the unique interface identifier. Other implementations do the same. Interface identifiers aren't required to be unique. Anyone who expects them to be be in trouble at some point. There are many ways in which the same interface identifier can show up in more than one subnet: - manual configuration (interface identifier 02-00-00-00-00-00-00-01 is very popular) - RFC 3041 and a whole lot of bad luck - there are systems on the market that use the same MAC address on more than one interface - there have been many screwups with MAC address assignment during production But what benefit is there to assuming that interface identifiers are unique anyway?
Re: IPv6 addressing limitations (was national security)
On 2-dec-03, at 21:04, Anthony G. Atkielski wrote: Why dedicated /64 to anything? We are getting by just fine on /32 for the whole world right now. Why is a sudden expansion of 2^32 required RIGHT NOW? Stateless autoconfiguration. See, that's the classic mistake: Everyone wants to divide the entire address space RIGHT NOW, without any clue as to how the world will evolve in years to come. Nature may abhor a vacuum, but it certainly also seems that engineers abhor unallocated address space, and will try to allocate everything even when they are lightyears off the mark About 85% of the IPv6 address space is specifically left unused at this time. And even within the 2000::/3 which is defined for global unicast use *now* just 3/8192th is really used.
RE: IPv6 addressing limitations (was national security)
Keith, Fortunately the mistake is easily rectified, so long as software doesn't get into the habit of expecting the lower 64 bits of an address to be a unique interface identifier. This is a dangerous prospect. The company I work for makes a networking stack and our IPv6 implementation expects the lower 64 bits to be the unique interface identifier. Other implementations do the same. Now would be the time to change the spec if its going to be done, otherwise it will already have market penetration just like NAT. Dan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Keith Moore Sent: Tuesday, December 02, 2003 1:03 PM To: Iljitsch van Beijnum Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: IPv6 addressing limitations (was national security) RFC 3513 mandates that all unicast IPv6 addresses except the ones starting with the bits 000 must have a 64-bit interface identifier in the lower 64 bits. This was shortsighted, just like having the notion of class built into IPv4 addresses was shortsighted. People are going to need to subnet past /64 sooner rather than later, and subnetting past /64 is a LOT better than NAT. Fortunately the mistake is easily rectified, so long as software doesn't get into the habit of expecting the lower 64 bits of an address to be a unique interface identifier. This has some important advantages, most notably it allows stateless autoconfiguration. Providing an alternative to stateless autoconfiguration for subnets past /64 might be a acceptable compromise. Putting a 64-bit crypto-based host identifier in the bottom 64 bits of IPv6 addresses shouldn't get in the way of regular IPv6 addressing mechanisms and/or operation. Putting a crypto-based host identifier in the address is unnecessary, since there's really no need to include a strong host identifier in every packet sent to a host. The locator alone is usually sufficient, and if that's not sufficient, the sender can generally encrypt the traffic with a secret known only to the intended destination. Keith
Re: IPv6 addressing limitations (was national security)
Fortunately the mistake is easily rectified, so long as software doesn't get into the habit of expecting the lower 64 bits of an address to be a unique interface identifier. This is a dangerous prospect. The company I work for makes a networking stack and our IPv6 implementation expects the lower 64 bits to be the unique interface identifier. Other implementations do the same. My advice would be for you and your competitors to fix this problem as part of your normal product improvement. Because sooner or later those whose products don't support subnets past /64 will lose business to those that do. It's all well and good to insist that ISPs give out /48s to their customers, but it's not wise to pretend that everyone will comply. There will be customers that can't get better than a /64 and will need to subnet.
Re: IPv6 addressing limitations (was national security)
Putting a crypto-based host identifier in the address is unnecessary, since there's really no need to include a strong host identifier in every packet sent to a host. The locator alone is usually sufficient, and if that's not sufficient, the sender can generally encrypt the traffic with a secret known only to the intended destination. Putting a 64 bit crypto-based identifier in IPv6 addresses isn't something that would be done because it's the only way to arrive at certain functionality, but rather because it's a convenient way to do it. The 64 bits are present in each packet anyway, and putting a crypto identififer in each packet is much simpler than thinking very hard about when one is required, and then find a good place for it. well, you have to do that thinking anyway in order to get multihoming, mobility, and renumbering to work right.
Re: IPv6 addressing limitations (was national security)
On 2-dec-03, at 20:03, Keith Moore wrote: RFC 3513 mandates that all unicast IPv6 addresses except the ones starting with the bits 000 must have a 64-bit interface identifier in the lower 64 bits. This was shortsighted, just like having the notion of class built into IPv4 addresses was shortsighted. People are going to need to subnet past /64 sooner rather than later, and subnetting past /64 is a LOT better than NAT. Fortunately the mistake is easily rectified, so long as software doesn't get into the habit of expecting the lower 64 bits of an address to be a unique interface identifier. Right. Fortunately the implementations that I'm familiar with seem to have ignored this requirement at least to some degree as they seem to function well with non 64-bit subnet boundaries. However, there is also another requirement that gets in the way of using very small subnets: the well-known anycast addresses. Since the address with all zero bits in the subnet part is the mandatory all subnet routers anycast address this address is unusable (even though this anycast address isn't universally implemented), and another 128 are reserved, making the smallest possible subnet a /126 or /120 respectively. This has some important advantages, most notably it allows stateless autoconfiguration. Providing an alternative to stateless autoconfiguration for subnets past /64 might be a acceptable compromise. DHCPv6 should work with non-/64 subnets as soon as it's integrated in the OSes. Putting a 64-bit crypto-based host identifier in the bottom 64 bits of IPv6 addresses shouldn't get in the way of regular IPv6 addressing mechanisms and/or operation. Putting a crypto-based host identifier in the address is unnecessary, since there's really no need to include a strong host identifier in every packet sent to a host. The locator alone is usually sufficient, and if that's not sufficient, the sender can generally encrypt the traffic with a secret known only to the intended destination. Putting a 64 bit crypto-based identifier in IPv6 addresses isn't something that would be done because it's the only way to arrive at certain functionality, but rather because it's a convenient way to do it. The 64 bits are present in each packet anyway, and putting a crypto identififer in each packet is much simpler than thinking very hard about when one is required, and then find a good place for it.
Re: IPv6 addressing limitations (was national security)
Iljitsch; Putting a 64-bit crypto-based host identifier in the bottom 64 bits of IPv6 addresses shouldn't get in the way of regular IPv6 addressing mechanisms and/or operation. Putting a crypto-based host identifier in the address is unnecessary, since there's really no need to include a strong host identifier in every packet sent to a host. The locator alone is usually sufficient, and if that's not sufficient, the sender can generally encrypt the traffic with a secret known only to the intended destination. Putting a 64 bit crypto-based identifier in IPv6 addresses isn't something that would be done because it's the only way to arrive at certain functionality, but rather because it's a convenient way to do it. Putting a 64 bit crypto-based identifier means people won't type that long hexadecimal sequence. That is, even if most people use DNS or something like that, it is still inconvenient for DNS administrators. Note that the value is psuedo random and completely different host by host that copying some digit of other host does not work. People relying on DNS do not notice even if a 64bit id from DNS is different from the specified one. There is no one who specifies the id. So, there is no security nor convenience. Masataka Ohta
