So discarding the discussions which can possible be classified as 'pissing contest' replies without any reasoning..
The difference in opinion is most of the IPV6 customer allocation size discussion revolves around a particular view of the end-user site size and the perceived potential network deployment that they may do.. Folks which are in the give them a larger prefix (smaller quantity of IP's) are from the camp which says my customers are not doing anything sophisticated, and I would like to monetize the allocation of smaller prefixes by being able to get an upgrade charge. Folks which are in the give them a smaller prefix (larger quantity of IP's) are from the camp which says, there is plenty to go around, don't try to split hairs .. just do the smaller prefix, this can be universal and provide enough flexibility to cover all potential scenarios, which may exist in the near or far future. And yes without having an deeper understanding on how the protocol works, it is very possible that such a discussion comes across as a pissing contest... (I am not an expert, am still learning.. but above is how I have been able to reconcile all the different discussions). Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net ----- Original Message ----- > From: "Ken Hohhof" <af...@kwisp.com> > To: af@afmug.com > Sent: Sunday, January 15, 2017 1:07:08 PM > Subject: Re: [AFMUG] Best Way to implement dual stack IPv4/6 > But still, I remember coming back from a WISPA show where I attended a session > on IPv6 implementation and best practices. Upon returning, people on the > lists > said those best practices were dead wrong. So while I may be naive wanting > someone to say here's a universal template, it seems no matter what you do > some > people will say you did it wrong. > > > -----Original Message----- > From: Af [mailto:af-boun...@afmug.com] On Behalf Of Faisal Imtiaz > Sent: Sunday, January 15, 2017 11:43 AM > To: af@afmug.com > Subject: Re: [AFMUG] Best Way to implement dual stack IPv4/6 > > I respectfully disagree with the analogy... > In case of religion opinions are based on beliefs..... > > In case of IPv6 there are underlying technical reasons of why the larger > prefix... > it is impossible to do a one-size that fits all... and some of those > reasons may > not be apparent or visible right away but that does not change them... > > Typically in IPv4 the thinking is top down.. i.e. we breakdown what we have, > and > assign the smallest qty of address then we use all the tricks in the book to > make them work... > > With IPv6, due to how the protocol is designed, for proper understanding, one > needs to look at it from bottom up... and instead of counting qty of IP > addresses needs to count the amount of subs-nets that can be carved out of the > allocation. > > Faisal Imtiaz > Snappy Internet & Telecom > 7266 SW 48 Street > Miami, FL 33155 > Tel: 305 663 5518 x 232 > > Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net > > ----- Original Message ----- >> From: "Ken Hohhof" <af...@kwisp.com> >> To: af@afmug.com >> Sent: Sunday, January 15, 2017 11:55:00 AM >> Subject: Re: [AFMUG] Best Way to implement dual stack IPv4/6 > >> So like religion, whatever you do, someone will fervently claim you >> are dead wrong and will burn in hell. >> >> >> -----Original Message----- >> From: Af [mailto:af-boun...@afmug.com] On Behalf Of Faisal Imtiaz >> Sent: Sunday, January 15, 2017 10:32 AM >> To: af@afmug.com >> Subject: Re: [AFMUG] Best Way to implement dual stack IPv4/6 >> >> You might want to review some of those recommendations... >> They don't fall into best practices....and can be problematic. >> >> There are many discussions and docs on this topic...A while ago I had >> a discussion on this topic on Nanog list.. >> >> There was a 'key' item pointed out to me and I had to grasp that to >> gain a full understanding on what size to assign. >> ... You have to think interns of subnet's and not qty of Addresses to >> assign properly. >> >> Here is an excellent presentation.. >> http://www.txv6tf.org/wp-content/uploads/2012/09/Doyle-IPv6-Address-De >> sign.pdf >> >> http://meetings.ripe.net/ripe-49/presentations/ripe49-ipv6-guidelines. >> pdf >> >> -------- >> explanation:- >> There is no concept of NAT in IPv6, and IPv6 networks by design are >> 'stacked routers' vs a traditional flat LAN (as in ipv4 networks). >> so it is important to provide the ability to break down the subnet >> that you assign to your customers.. >> >> e.g. >> a /64 is / should be the smallest level of assignment (this of a LAN, or >> any >> Link (PTP or PTMP).) i.e. one lan segment >> a /56 would allow for 256 Lan Segments... or a 8 level deep network >> a /48 would allow for 65536 Lan segments or a 16 level deep network >> (I am going my memory on the network level depth, so I may be over >> estimating.. >> :) ) >> >> There is a lot of wisdom behind assign a /48 to each customer.. .and >> there is a lot of discussion on doing something a bit smaller for >> smaller customers e.g. a /56. >> >> Think of it this way... IPv6 is how IoT communicates.. and each device >> connecting to the 'home network' can act as a router, thus a layers.. >> e.g. Smart Cars, will have a router, to connect to devices in the car, >> and it will connect to the home network as a sub layer network... etc... >> >> Regards >> >> Faisal Imtiaz >> Snappy Internet & Telecom >> 7266 SW 48 Street >> Miami, FL 33155 >> Tel: 305 663 5518 x 232 >> >> Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net >> >> ----- Original Message ----- >>> From: "Paul Stewart" <p...@paulstewart.org> >>> To: "Animal Farm" <af@afmug.com> >>> Sent: Sunday, January 15, 2017 8:05:45 AM >>> Subject: Re: [AFMUG] Best Way to implement dual stack IPv4/6 >> >>> Ok .. lots of folks here can probably help but you’ll need to be a >>> bit more specific :) >>> >>> Advise on planning for it? Implementing it on specific gear? last >>> mile to customer? … over entire deployment? >>> >>> Here’s some info that may help (from network perspective): >>> >>> Full dual stack deployment across network with Juniper MX throughout >>> /126 for point to point >>> /128 for loopback >>> OSPFv3 for connected networks and loopbacks iBGP for full internal >>> and external routes (where needed) >>> >>> For DSL/Wireless (PPPOE): >>> /40 and /47 IP pools per device that is serving customers (varies >>> with number of customers per device) Customers receive /64 allocation >>> via DHCP-PD over their existing PPPOE connection >>> >>> For Cable (DHCP): >>> /48 and /56 IP pools per geographic region that is serving customers >>> Customers receive /64 allocation via DHCP-PD >>> >>> For fiber (static or BGP) >>> /126 point to point >>> /64 allocation by default, /56 upon request, larger if justified >>> >>> >>> I’ve pretty much followed this model in one form or other since 2008 >>> when I did the first network end to end >>> >>> Paul >>> >>> >>> >>> >>>> On Jan 14, 2017, at 11:58 PM, Mitch Koep <af...@abwisp.com> wrote: >>>> >>>> Need some advise on implementing dual stack. >>>> >>>> Best practice or practical. >>>> >>>> Thanks >>>> >>>> Mitch Koep >>>> > > >> 219-851-8689 cell
