IPv6 daydreams
David Barak
thegameiam at yahoo.com
Thu Oct 20 03:39:11 UTC 2005
--- David Conrad <drc at virtualized.org> wrote:
> On Oct 17, 2005, at 10:39 PM, Paul Jakma wrote:
> >> 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-
__________________________________
Yahoo! Music Unlimited
Access over 1 million songs. Try it free.
http://music.yahoo.com/unlimited/
More information about the NANOG
mailing list