What I'm unhappy
about is the exceedingly sparse allocation policies
which mean that any enduser allocation represents a
ridiculously large number of possible hosts.
See the HD ration + proposals about sizing it down to a /56 as mentioned
in my previous mail to this list.
The only
possible advantage I could see from this is the
protection against random scanning finding a user -
but new and fun worms will use whatever mechanism the
hosts use to find each other: I guarantee that the
"find a printer" function won't rely on a sequential
probe of all of the possible host addresses in a /64
either...
SDP, uPnP, DNSSD etc and most likely also using ff02::1 and other
multicast tricks.
The important thing here though is that you already have
a local address
Also, the 64-bit addressing scheme is sized to include
the MAC address, right? Why would encoding L2 data
into L3 be a good thing?
Because this gives you an automatic unique IP address.
Also some L2's (firewire comes to mind) have 64 bit EUI's.
The conceptual problem that
I have had with v6 from the beginning is that it's not
trying to optimize a single layer, it's really trying
to merge several layers into one protocol. Ugh.
One could, at least in theory and afaik not tried yet, run IPv6 as L2 
Greets,
Jeroen
so, if we had a free hand and ignored the dogmas, what would we
change about the v6 architecture to make it really deployable
and scalable and have compatibility with and a transition path
from v4 without massive kludging, complexity, and long term
cost?
Isn't that GENI already out of the bottle?
http://www.nsf.gov/cise/geni/
http://www.ana.lcs.mit.edu/papers/PDF/Rethinking_2001.pdf
http://cfp.mit.edu/docs/overview.pdf
http://cfp.mit.edu/groups/internet/internet.html
Seems like there is enough interest in this to plan something
for NANOG 36 early next year.
--Michael Dillon
You can allocate to 100% density on the network identifier if you want, right down to /64.
The host identifier simply is indivisible, and just happens to be 64bit.
regards,
Wrong issue. What I'm unhappy about is not the size of the address - you'll notice that I didn't say "make the whole address space smaller." What I'm unhappy about is the exceedingly sparse allocation policies
You can allocate to 100% density on the network identifier if you want, right down to /64.
I believe the complaint isn't about what _can be_ done, rather what _is being_ done.
The host identifier simply is indivisible, and just happens to be 64bit.
I've always wondered why they made a single "address" field if the IPv6 architects really wanted a hard separation between the host identifier and the network identifer. Making the "address" a contiguous set of bits seems to imply that the components of the "address" can be variable length.
Rgds,
-drc
>> Wrong issue. What I'm unhappy about is not the
size of the
>> address - you'll notice that I didn't say "make
the whole address
>> space smaller." What I'm unhappy about is the
exceedingly sparse
>> allocation policies
> You can allocate to 100% density on the network
identifier if you
> want, right down to /64.
I believe the complaint isn't about what _can be_
done, rather what
_is being_ done.
Yes and yes. I am certainly complaining about what
*is* being done. See below for my bigger issue.
> The host identifier simply is indivisible, and
just happens to be
> 64bit.
I've always wondered why they made a single
"address" field if the
IPv6 architects really wanted a hard separation
between the host
identifier and the network identifer. Making the
"address" a
contiguous set of bits seems to imply that the
components of the
"address" can be variable length.
Now we're cooking with gas: what we've learned from
MAC addresses is that it's really nice to have a
world-unique address which only has local
significance.
The /64 "host identifier" is a misnomer: there are
folks who use /127s and /126s for point-to-point
links, and there are all sorts of variable length
masks in use today.
The whole reason for a /64 to be associated with a
host is to have enough room to encode MAC addresses.
I ask again - why exactly do we want to do this?
Layer-2 works just fine as a locally-significant host
identifier, and keeping that out of layer-3 keeps
everything considerably simpler.
-David Barak-
-Fully RFC 1925 Compliant-