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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf