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