[ipv6-wg] IPv6 prefix delegation BCOP document available for comments and suggestions

Hello,

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
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
3.2.1: which mechanisms use a default /48 prefix size? Could you please 
elaborate a bit?
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?
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)

As more general final comment, I believe that such a document would 
definitely benefit operators just starting out

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.