On 2011-03-04 10:59, Manfredi, Albert E wrote: > 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.
Then their customers will discover that they need to switch to another ISP, won't they? Brian > > 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 --------------------------------------------------------------------
