I'm not quite sure what point you're making.
If it's the size of the network part or the host part of an IPv6
address, as I recall the logic, the original stated requirement was
that an ipng address should be able to represent 10^12 networks (42
bits) and 10^15 hosts (52 bits). Considering the H ratio and the way
the network and host part of an IPv4 address was/is used, one could
have imagined an address that set aside 43 or more bits for the host
part and 11 or more bits for the host part. That was the basis for
SIP's 64 bit address.
Somewhere along the way, it was decided that a 128 bit address was
more appropriate - if 32 bits isn't enough for all uses for all time,
who says 64 is? Long story there that I wasn't a party to. But OK, it
became 128 bits, and someone started talking about maybe using the
MAC address in the host part. Someone noted that not all MAC
addresses were 48 bits; for example, an E.164 address (a telephone
number by any other name) when represented as BCD digits might easily
be 16 digits, and some 802 series addresses are 64 bits. So it was
suggested that 64 bits be set aside for the host part.
That left the network part. There have been numerous discussions
about that, which I would summarize as the operators feeling a need
for flexibility, the IETF making some recommendations, and changing
those recommendations over time.
If your point is that 64 bits exceeds 48 bits, yes, but 48 bits
doesn't meet the felt need. If it's not, then where are you going
with the question?
On Sep 17, 2007, at 4:24 PM, Brian Dickson wrote:
The following is meant to be used for demonstration purposes.
It is meant for any and all to make reference to in discussions
where "16 bits" may come into play.
(I anticipate sending out something soon which does just that. ;-))
What's 16 Bits Between Friends?
In any discussion about protocols, where an object is sized as N
bits, there will inevitably come a discussion about specific values
for N.
There may be tendencies to make values of N divisible evenly by 4,
8, 16, or even 32.
Similarly, this may occur for choices for constituent parts, where
there is a trade-off between size of the object component, and the
number of objects that might be seen.
So, what is the case against something having an "extra" 16 bits,
meaning 16 bits more than is likely necessary even in the most
extreme of high-ball predictions for need?
That's where a simple example can illustrate what an "extra" 16
bits really looks like.
Consider a physical object, something that is itself quite common:
the rest-room key for a coffee shop.
The key itself has no intrinsic value, but the lack of a key can
have dire consequences (at least to the prospective user of the
rest-room.)
Accordingly, common practice is to attach the key to a suitably
sized object, small enough to be carried, but large enough so that
it does not fit in a pocket.
One common object is the hub-cap of an automobile's wheel (sans
wheel and automobile, of course!). A hubcap is approximately 1
square foot, or 0.1 m^2 in area.
The key is not bolted directly on, but instead typically attached
by a short cord or chain, usually about 4 inches (0.1m).
So, what happens if we enlarge either the hubcap, or the chain, by
16 bits? It becomes 65536 times the size.
The hubcap grows to the size of the deck of an aircraft carrier.
The chain or cord, becomes 6.5km long.
I would argue, then, that 16 bits too much, is *way* too much, in
pretty much any situation. The example makes this, one would hope,
self-evident.
(The presumption must be maintained, however, that the underlying
object is appropriately sized to begin with, otherwise the analogy
fails.)
Brian
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
