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@ripe.net> en nombre de Jan Zorz - Go6 <jan@go6.si> Responder a: <jan@go6.si> Fecha: martes, 11 de abril de 2017, 10:53 Para: <ipv6-wg@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.