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

On 11/04/2017 10:56, JORDI PALET MARTINEZ wrote:
> I guess some of those questions have already been improved in the
> latest edits last week. Maybe we should publish them so people is
> commenting from the last version?

Hey, Jordi

Yes, I'm aware of that, but I would not like to create confusion. Let's
collect the feedback, do the edit cycle and publish the second version
of the draft that people can go and read again and comment. Having a
semi-baked intermediate versions between full edit-cycle versions would
just create confusion.

Cheers, Jan

> 
> Saludos, Jordi
> 
> 
> -----Mensaje original----- De: ipv6-wg <ipv6-wg-bounces at ripe.net> en
> nombre de Jan Zorz - Go6 <jan at go6.si> Responder a: <jan at go6.si> 
> Fecha: martes, 11 de abril de 2017, 10:53 Para: <ipv6-wg at ripe.net> 
> Asunto: Re: [ipv6-wg] IPv6 prefix delegation BCOP document available
> for comments and suggestions
> 
> 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.
>> 
>> 
> 
> 
> 
> 
> 
> 
> ********************************************** IPv4 is over Are you
> ready for the new Internet ? http://www.consulintel.es The IPv6
> Company
> 
> This electronic message contains information which may be privileged
> or confidential. The information is intended to be for the use of the
> individual(s) named above. If you are not the intended recipient be
> aware that any disclosure, copying, distribution or use of the
> contents of this information, including attached files, is
> prohibited.
> 
> 
> 
>