This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[ipv6-wg] IPv6 prefix delegation BCOP document available for comments and suggestions
- Previous message (by thread): [ipv6-wg] IPv6 prefix delegation BCOP document available for comments and suggestions
- Next message (by thread): [ipv6-wg] IPv6 prefix delegation BCOP document available for comments and suggestions
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
JORDI PALET MARTINEZ
jordi.palet at consulintel.es
Tue Apr 11 10:56:21 CEST 2017
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? 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.
- Previous message (by thread): [ipv6-wg] IPv6 prefix delegation BCOP document available for comments and suggestions
- Next message (by thread): [ipv6-wg] IPv6 prefix delegation BCOP document available for comments and suggestions
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ ipv6-wg Archives ]