On Thu, 27 Dec 2007 18:08:10 -0800 "Scott Weeks" <[EMAIL PROTECTED]> wrote:
> > > > > First, thanks everyone for the discussion. I learned more from this than a > LOT of other discussions on IPv6. I now have a plan and I didn't before... > > It looks to me that one really has to know his customer's needs to plan out > the allocation of IPv6 space. That leads me to believe that a /56 is going > to work for everyone on this network because, at this time, only very, very > few of our largest customers might possibly have a need for more than 256 /64 > subnets. In fact, almost all household DSL customers here only have one LAN > and I could get away with /64s for them because they wouldn't know the > difference. But in an effort to simplify the lives of the network folks here > I am thinking of a /56 for everyone and a /48 on request. > Out of curiosity, what in form would a request for a /48 need to be? A checkbox on the application form, or some sort of written justification? Remember that with an initial RIR allocation of a /32, you've got 65K /48s ... so they're pretty cheap to give away. > Now I just gotta wrap my brain around 4.7x10^21 addresses for each customer. > Absolutely staggering. > Ever calculated how many Ethernet nodes you can attach to a single LAN with 2^46 unicast addresses? That's a staggering number too. Regards, Mark. > scott > > > > --- [EMAIL PROTECTED] wrote: > > From: Randy Bush <[EMAIL PROTECTED]> > To: Joel Jaeggli <[EMAIL PROTECTED]> > CC: nanog@merit.edu > Subject: Re: v6 subnet size for DSL & leased line customers > Date: Thu, 27 Dec 2007 13:19:27 +0900 > > > >> vendors, like everyone else, will do what is in their best interests. > >> as i am an operator, not a vendor, that is often not what is in my best > >> interest, marketing literature aside. i believe it benefits the ops > >> community to be honest when the two do not seem to coincide. > > If the ops community doesn't provide enough addresses and a way to use > > them then the vendors will do the same thing they did in v4. > > i presume you mean nat v6/v6. this would be a real mess and i don't > think anyone is contending it is desirable. but this discussion is > ostensibly operators trying to understand what is actually appropriate > and useful for a class of customers, i believe those of the consumer, > soho, and similar scale. > > to summarize the positions i think i have heard > o one /64 subnet per device, but the proponent gave no estimate of the > number of devices > o /48 > o /56 > o /64 > the latter three all assuming that the allocation would be different if > the site had actual need and justification. > > personally, i do not see an end site needing more than 256 subnets *by > default*, though i can certainly believe a small minority of them need > more and would use the escape clause. so, if we, for the moment, stick > to the one /64 per subnet religion, than a /56 seems sufficient for the > default allocation. > > personally, i have a hard time thinking that any but a teensie minority, > who can use the escape clause, need more than 256. hence, i just don't > buy the /48 position. > > personally, i agree that one subnet is likely to be insufficient in a > large proportion of cases. so keeping to the /64 per subnet religion, a > /64 per site is insufficient for the default. > > still personally, i think the one /64 subnet per device is analogous to > one receptacle per mains breaker, i.e. not sensible. > > > there are three legs to the tripod > > network operator > > user > > equipment manufacturer > > They have (or should have) a mutual interest in: > > Transparent and automatic configuration of devices. > > as you have seen from chris's excellent post [0] on this one, one size > does not fit all. this is likely another worthwhile, but separate, > discussion. > > > The assignment of globally routable addresses to internet > > connected devices > > i suspect that there are folk out there who equate nat with security. i > suspect we both think them misguided. > > > The user having some control over what crosses the boundry > > between their network and the operators. > > yup > > randy > > --- > > [0] - <http://www.merit.edu/mail.archives/nanog/msg04887.html> > > -- "Sheep are slow and tasty, and therefore must remain constantly alert." - Bruce Schneier, "Beyond Fear"