I guess I'm missing what the solution is. As 3177-bis says, the IETF has no control over how service providers hand out IPv6 address space. From what I've been reading in the past few years, it looks like at least some providers are planning to give /64s to customers.
The way I see it, unless we permit SLAAC to use more than 64-bit prefixes, either of two things will happen. 1. SLAAC will not work inside home networks, except for the simplest one-computer case, or 2. Someone will have the brilliant idea to invent an IPv6 NAT. As Mark points out, this may encourage providers to hand out /127s. So, rock and hard place. What's the answer, if no one can force providers to hand out AT LEAST /56s? NAT? Bert > -----Original Message----- > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of > Brian E Carpenter > Sent: Thursday, March 03, 2011 4:41 PM > To: Mark Smith > Cc: Thomas Narten; ipv6; Scott W Brim; Duncan,Richard J. (Jeremy) > CONTRACTOR; Yu Hua bing > Subject: Re: [BULK] Re: draft-yhb-6man-slaac-improvement-00 > > 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? > >> > >> > >> > >> > >> > >> > 01010011011001010110110101110000011001010111001000100000010001100110100 > 1 > >> > >> 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
