On 11/04/2017 10:40, Yannis Nikolopoulos wrote: > Hello, Hey,
Thnx for your time and effort to read the draft, much appreciated! > > a few (late) comments: > > 3.1.1: When exactly is this a good idea and why reference an old > draft?(We have 6164) > 3.1.4 ULA: Since numerous problems may be caused by this approach, I > believe that more than one should be mentioned Any suggestion what to add (and not to make it too long)? > 3.2.1: users not being able to use all 4 hex digits can lead to > erroneous allocations outside of /56? This sounds a bit stretched People does strange things ;) > 3.2.1: which mechanisms use a default /48 prefix size? Could you please > elaborate a bit? That was some tunneling mechanisms, Jordi can explore more. I would just remove that section, but Jordi wants to elaborate on this ;) > 3.2.2: /48 for all is most practical & most pragmatic? How many /32 we > need to burn for our end users? We have ~1.6M residential users and our > /29 is definitely not enough. Is RIPE onboard with that? Why not ;) If you burn your IPv6 space, you get new allocation. This should not be a problem, specially because RIPE NCC default mathematics is based on /48-per-customer, at least that's what I remember. > 4.2. even though I generally agree that dynamic assignments have more > disadvantages (than benefits), the need to have a logging system is > usually not one of them, as most (if not all) ISPs have that covered > long before IPv6 (e.g. RADIUS accounting) ack. > > As more general final comment, I believe that such a document would > definitely benefit operators just starting out Thnx!!! Cheers, Jan > > cheers, > Yannis > > On 03/27/2017 04:32 PM, Jan Zorz - Go6 wrote: >> Dear RIPE IPv6 WG, >> >> As promised at last RIPE meeting in Madrid, we produced a first draft of >> "Best Current Operational Practice for operators: IPv6 prefix assignment >> for end-users - static (stable) or dynamic (non-stable) and what size to >> choose." >> >> The aim of this document is to document the best current operational >> practice on what size of IPv6 prefix ISPs should assign/delegate to >> their customers and should they delegate it in a stable, static way or >> should it change over time. >> >> Please find the PDF attached and also accessible at: >> >> https://www.sinog.si/docs/draft-IPv6pd-BCOP-v1.pdf >> >> We are submitting this document to RIPE IPv6 WG (here) to check the >> technical validity of the document and also get consensus on it. We are >> also submitting it to RIPE BCOP TF to check if this is a >> real best operational practice and get consensus on it there. >> >> Please, read the document and send back comments to this mailing list. >> All feedback is more than welcome. >> >> On behalf of co-authors, Jan Ε½orΕΎ >> >> P.S: This document is not intended to document what practices may >> be in future and what they might look like, but to reflect the best >> methods of implementing IPv6 at the time of publication. Updates to this >> document will be published to reflect changes in best current practices >> where there are developments in standards and implementations. > >
