At 17:21 -0700 2007/09/17, Fred Baker wrote:
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.
And this is where they went seriously wrong as did CLNP.
By the early 80s, we had figured out that the obvious approach of
using the lower layer address in the higher layer protocol is
seriously flawed. That approach is equivalent to creating a
*pathname* as in Operating Systems. (It works in OSs, because there
*is* only one way to get any where, but doesn't work in networks,
except for SNA, because, well, they are networks.)
The address is suppose to be route independent, specifying "where"
without constraining "how to get there." This does the opposite and
merely compounds the error made with the original IMP addressing that
we are still living with. This is why we are having and will
continue to have so much trouble with multihoming, mobility, scaling
and a host of other problems.
IPv6 crawled into this hole a long time ago. It is a little late to
be trying to crawl out. Time to move on.
Take care,
John
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
