Hi, I think your fundamental premise is flawed. You're saying that as an upstream provider is precious about address space, and only going to give out a /64, that it should be possible to subnet that /64 further. Unfortunately all I think that will do is also facilitate the upstream provider pushing the initial allocation boundary even further to the right. A really "precious" upstream provider will start handing out /127s, /126s etc. because they now can - only as many as they perceive you to "need" right now. You'll have to justify the exact amount of address space you want, you'll have to deal with them again to get more, and they'll have to manage their IPv6 address space at an address rather than subnet level. All these costs are necessary ones in IPv4, but don't need to exist in IPv6. There are no useful benefits to be gained from paying them.
One thing I'm noticing is that when people find out that a /64 is the basic minimum size for a subnet, and that it's all about numbers of subnets, rather than numbers of addresses, they start to slowly stop applying their IPv4 conserve addresses addresses mentality to IPv6. I think moving away from a single and fixed size interface id will start to encourage people to become more conservative again, unnecessarily. Oh, and "waste" only occurs if you get no value when you use something - " In fact, any LAN can't run out of so many IPv6 addresses, and only a very small part of IPv6 addresses are used, so it is a serious waste." The value you get out of IPv6's (and also in fact Ethernet's) large address space is convenience. If you have a car with an automatic transmission, or electric windows, or central locking, or even an electric start (i.e. you're not hand winding it to start it), you've already placed value on having convenience. If the costs are low enough (e.g. cheap addressing bits), data networking protocols should be convenient to use too. Regards, Mark. On Thu, 3 Mar 2011 23:02:22 +0800 "Yu Hua bing" <[email protected]> wrote: > If the prefix is longer than 64, don't use EUI-64 interface ID. > > (7.2)If the prefix length is greater than 64 and is not greater than > 80, an address is formed by combining the advertised prefix with > the MAC address of the interface as follows: > > | N bits | (80 - N) bits | 48 bits | > +------------------------------+---------------+-----------------+ > | link prefix | reserved | MAC address | > +----------------------------------------------------------------+ > (7.3) If the prefix length is greater than 80, a random number > between 0 and 2 ^ (128 - prefix length) is generated, and an address > is formed by combining the advertised prefix with the random number > as follows: > > | N bits | 128 - N bits | > +---------------------------------------+------------------------+ > | link prefix | random number | > +----------------------------------------------------------------+ > > > > > From: Duncan, Richard J. (Jeremy) CONTRACTOR > Sent: Thursday, March 03, 2011 10:56 PM > To: Yu Hua bing ; [email protected] ; Brian E Carpenter > Cc: Thomas Narten ; ipv6 ; Scott W Brim > Subject: RE: [BULK] Re: draft-yhb-6man-slaac-improvement-00 > > > I think that SLAAC should be deployed in the sites which use the prefixes > longer than 64. > > Don't put a limit on the prefix length. > > DHCPv6 can be deployed in the sites which use the prefixes longer than 64.Why > can't SLAAC? > > It is not reasonable. > > > > No. EUI-64 requires 64 bit host id's. 48 bits is from the MAC. How would > you plan to squeeze blood out of the proverbial turnip? > > > > > > 010100110110010101101101011100000110010101110010001000000100011001101001 > > Jeremy Duncan > > Defense Threat Reduction Agency (DTRA) > BE-BI INFOCON 3, IPv6 Architect > Command Information > Google Voice: (540) 440-1193 > > > -------------------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
