kre, >> Michel Py wrote: >> I concur that it would not be wise to assume anything, but saving IPv6 >> addresses does not strike me as good idea if it brings more complexity >> and does not bring anything else than allocation efficiency.
> Robert Elz wrote: > I probably wouldn't either, though we don't want to totally forget > allocation efficiency - the way we make sure that IPv6 never runs out > is to always make sure we justify every allocation (which doesn't mean > organisations need to justify their need for a /48 - but I'd certainly be > making any organisation asking for a 2nd one (in the same aggregatable > block, I'm not talking about multi-connecting here) justify their use > of the first /48 they were allocated before giving away another. Concur. But let's get back where this thread was a few postings ago, which is subneting inside the IID. In the act of balancing complexity and allocation efficiency, do we say: 1. It is ok to use a /64 for loopbacks and point to point links in the sake of simplicity. 2. It is a waste to use a /64 for a loopback or a point-to-point link and therefore we should subnet the IID. My vote goes to 1. Large address space is not new. IPX has 32 network bits, (see my previous post about the IPX internal net); IPv6 has 64 network bits. I do not think we need more. Using a /64 for a loopback or a point-to-point is perfectly compatible with efficient allocation as well as simplicity. > But not adding any explicit length limits doesn't add complexity, it > reduces it. I have to disagree with you here. Although these were different times, addressing schemes such IPX, Appletalk phII and classful IP that had fixed boundaries were a lot simpler for most. In IPv6, there already are things (autoconf, privacy, EUI-64) that assume a /64 subnet size. There is nothing that forbids subneting into the IID (although it would be difficult to subnet smaller than /80), but don't you think that, in the time being, it would be wise to stick to /64 unless we have a hell of a good reason? Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
