[EMAIL PROTECTED] wrote: > It seems that someone in ARIN land believes that IPv6 addresses are > scarce resources that need to be carefully dribbled out to customers > according to need. The following proposal has just been formally made to > change ARIN's allocation policy. > > ------start of copied text------ > > Replace the text in section 6.5.4.1 with the following text: > > LIR's may assign blocks in the range of /48 to /64 to end sites. > All assignments made by LIR's should meet a minimum HD-Ratio of .25. > > * /64 - Site needing only a single subnet. > * /60 - Site with 2-3 subnets initially. > * /56 - Site with 4-7 subnets initially. > * /52 - Site with 8-15 subnets initially. > * /48 - Site with 16+ subnets initially. > > For end sites to whom reverse DNS will be delegated, the LIR/ISP should > consider making an assignment on a nibble (4-bit) boundary to simplify > reverse lookup delegation. > > LIR's do not need to issue all 5 sizes of prefixes as long as the > HD-Ratio requirement is met.
If you get ivp6 address space you should receive enough that you won't have to come back, whether you're a residential customer recieving it from your isp, an end site that part of a larger entity or a customer of an isp, or meet the classical definition of an isp . given that point to point links are generally numbered as /64s assigning an end site something smaller than a /56 is likely to result in a number of scenario's where that address space is quickly exhausted. Repeated returns for more address space eventually result in fragmentation in the absence of careful manangement of initial allocation or renumbering which people have been generally loath to do. Within our block 2001:490:: we have as a general rule been handing out /48s to end sites within the enterprise that require subnetting. That give them a couple bits to further subdivide if necessary and enough /64s that they shouldn't be coming back for more anytime soon. It seems likely that cable mso's similar will dole out /64's to customers one at a time, I suppose that's acceptable if not necessarily desirable and will probably still result in the use of nat mechanisms in end systems. > ------end of copied text------ > > --Michael Dillon > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
