Yes, and in fact draft-ietf-v6ops-3177bis-end-sites deals with this and will be an RFC soon:
https://datatracker.ietf.org/doc/search/?name=draft-ietf-v6ops-3177bis-end-sites&rfcs=on&activeDrafts=on Regards Brian Carpenter On 2011-03-04 10:00, Mark Smith wrote: > 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" <yhb810...@gmail.com> 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 ; trej...@gmail.com ; 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 ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
