From nathalie at ripe.net Mon Apr 3 15:55:47 2017 From: nathalie at ripe.net (Nathalie Trenaman) Date: Mon, 3 Apr 2017 16:55:47 +0300 Subject: [bcop] IPv6 prefix delegation BCOP document available for comments and suggestions In-Reply-To: <6a960c0d-1e78-7ab9-34b3-635b03a4d6e5@go6.si> References: <6a960c0d-1e78-7ab9-34b3-635b03a4d6e5@go6.si> Message-ID: <31E7EC4E-FF36-4F51-93CE-3ECBAAE8F45A@ripe.net> Hi Jan, Great doc, and very readable. Thanks to all the authors for their input. I went over the doc with the eyes of a newbie to this stuff and found some areas for clarification. In section 3, we mention "end-user" for the first time, without explaining what an end-user is in this context.. In our courses we have to make that explanation sooner than later, because different audiences read different things in the word ?end-user?. The abbreviation of CPE is nowhere explained or fully written. Can we provide a link to an explanation of the Neighbor Discovery exhaustion attack? 3.1.3 where we mention ?This method may be seen as easier to implement, but it also brings some drawbacks such as difficulties with troubleshooting?, can we make it a bit more explicit by stating that link-local addresses don?t appear in a trace route, for example? 3.2.1 ?It should be remembered that some mechanisms use a default /48 prefix size ? Do we have examples? 3.2.3. I would make ?There is a clear exception to this rule when assigning addresses in a cellular network. I n this case a /64 will need to be provided for each PDP context for cellular phones, whereas for LTE modems/routers it will still be necessary to choose a /48 or /56, in accordance with the aforementioned considerations.? the paragraph after ?assigning a /64 or smaller prefix is highly discouraged? 4. ?Static assignment means that a prefix is assigned to a customer (typically an AAA) ? What is an AAA? Try to explain abbreviations. 4.1 ?The easiest way method? remove way or method. 4.2 ?If the CPE knows that the delegated prefix has changed it should send out RA packets? Write Router Advertisements. Did the authors consider images to explain certain concepts? For example bit boundary? RIPE NCC can help with that, if you wish. I hope this input is useful. Thanks again! Nathalie K?nneke-Trenaman IPv6 Program Manager RIPE NCC > On 27 Mar 2017, at 15:30, Jan Zorz - Go6 wrote: > > Dear RIPE BCOP community, > > 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 BCOP TF (here) to check if this is a > real best operational practice and get consensus on it. We are also > submitting this document to RIPE IPv6 WG to check the technical validity > of the document and also get consensus on it. > > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan at go6.si Mon Apr 3 16:34:17 2017 From: jan at go6.si (Jan Zorz - Go6) Date: Mon, 3 Apr 2017 16:34:17 +0200 Subject: [bcop] IPv6 prefix delegation BCOP document available for comments and suggestions In-Reply-To: <31E7EC4E-FF36-4F51-93CE-3ECBAAE8F45A@ripe.net> References: <6a960c0d-1e78-7ab9-34b3-635b03a4d6e5@go6.si> <31E7EC4E-FF36-4F51-93CE-3ECBAAE8F45A@ripe.net> Message-ID: <997696db-fb3d-d42a-74c2-9e6d1404da54@go6.si> On 03/04/2017 15:55, Nathalie Trenaman wrote: > Hi Jan, > > Great doc, and very readable. Thanks to all the authors for their input. > I went over the doc with the eyes of a newbie to this stuff and found > some areas for clarification. Hi Nathalie, Thank you for review, much appreciated!!! > > In section 3, we mention "end-user" for the first time, without > explaining what an end-user is in this context.. In our courses we have > to make that explanation sooner than later, because different audiences > read different things in the word ?end-user?... > 4.2 > ?If the CPE knows that the delegated prefix has changed it should send > out RA packets? > Write Router Advertisements. Agree. I implemented in the document majority of the above suggestions, thnx again for making this document better! > > Did the authors consider images to explain certain concepts? For example > bit boundary? RIPE NCC can help with that, if you wish. Should we? Isn't teaching the subnetting a little bit out of the scope of this document? Or would you like to replace the existing attempts to show the nibble boundaries in the document? Cheers and thnx, Jan > > I hope this input is useful. > > Thanks again! > > Nathalie K?nneke-Trenaman > IPv6 Program Manager > RIPE NCC > > >> On 27 Mar 2017, at 15:30, Jan Zorz - Go6 > > wrote: >> >> Dear RIPE BCOP community, >> >> 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 BCOP TF (here) to check if >> this is a >> real best operational practice and get consensus on it. We are also >> submitting this document to RIPE IPv6 WG to check the technical validity >> of the document and also get consensus on it. >> >> 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. >> > From swmike at swm.pp.se Mon Apr 3 16:40:13 2017 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 3 Apr 2017 16:40:13 +0200 (CEST) Subject: [bcop] IPv6 prefix delegation BCOP document available for comments and suggestions In-Reply-To: <31E7EC4E-FF36-4F51-93CE-3ECBAAE8F45A@ripe.net> References: <6a960c0d-1e78-7ab9-34b3-635b03a4d6e5@go6.si> <31E7EC4E-FF36-4F51-93CE-3ECBAAE8F45A@ripe.net> Message-ID: On Mon, 3 Apr 2017, Nathalie Trenaman wrote: > the paragraph after ?assigning a /64 or smaller prefix is highly > discouraged? Hi, I also like this document. I would put a reference somewhere to: https://www.broadband-forum.org/technical/download/TR-177.pdf "A delegated prefix for use within the home network (mandatory). The Broadband Forum suggests a size for the delegated prefix of at least a /60 for home network or SOHO environments, with a recommended prefix length of /56. The delegated prefix may be extended to a /48 for larger organizations." Just to at least say that /64 is defective, and all documents I have read from organizations that write about this, says at least /60, most recommend /56. Piling on that BBF agrees probably wouldn't hurt. -- Mikael Abrahamsson email: swmike at swm.pp.se From nathalie at ripe.net Mon Apr 3 16:44:57 2017 From: nathalie at ripe.net (Nathalie Trenaman) Date: Mon, 3 Apr 2017 17:44:57 +0300 Subject: [bcop] IPv6 prefix delegation BCOP document available for comments and suggestions In-Reply-To: <997696db-fb3d-d42a-74c2-9e6d1404da54@go6.si> References: <6a960c0d-1e78-7ab9-34b3-635b03a4d6e5@go6.si> <31E7EC4E-FF36-4F51-93CE-3ECBAAE8F45A@ripe.net> <997696db-fb3d-d42a-74c2-9e6d1404da54@go6.si> Message-ID: <817E0C6D-535D-4CAB-A04F-77E39B65A3E4@ripe.net> Hi, >> >> Did the authors consider images to explain certain concepts? For example >> bit boundary? RIPE NCC can help with that, if you wish. > > Should we? Isn't teaching the subnetting a little bit out of the scope of this document? Or would you like to replace the existing attempts to show the nibble boundaries in the document? > > Cheers and thnx, Jan Don?t know. I like plain-text docs because they are light-weight to download, but I am a visual learner myself (a picture says more than a thousand words). Also, because some readers might not be too familiar with English, a picture might help. I would suggest a picture for -nibble boundaries Highlight in bold the differences in: 2001:db8:aaaa:1a00::/56 2001:db8:aaaa:1b00::/56 2001:db8:aaaa:1c00::/56 2001:db8:aaaa:1d00::/56 and 2001:db8:aaaa::/48 2001:db8:aaab::/48 2001:db8:aaac::/48 2001:db8:aaad::/48 But that is basically it, now that I read it back. Maybe others have suggestions for this? Like I said, the doc works without images, but it might help. Cheers, Nathalie -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Mon Apr 3 16:48:50 2017 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Mon, 03 Apr 2017 16:48:50 +0200 Subject: [bcop] IPv6 prefix delegation BCOP document available for comments and suggestions In-Reply-To: <31E7EC4E-FF36-4F51-93CE-3ECBAAE8F45A@ripe.net> References: <6a960c0d-1e78-7ab9-34b3-635b03a4d6e5@go6.si> <31E7EC4E-FF36-4F51-93CE-3ECBAAE8F45A@ripe.net> Message-ID: <7695C132-DF2D-42BA-95D7-7E8B6B1A4712@consulintel.es> Hi Nathalie, Not sure if we need to coordinate the opinions among the authors, as it was quite difficult to agree on the actual text ? but I think I should go ahead ? Below in-line ? with ? Regards, Jordi -----Mensaje original----- De: BCOP en nombre de Nathalie Trenaman Responder a: Fecha: lunes, 3 de abril de 2017, 15:55 Para: Jan Zorz - Go6 CC: Asunto: Re: [bcop] IPv6 prefix delegation BCOP document available for comments and suggestions Hi Jan, Great doc, and very readable. Thanks to all the authors for their input. I went over the doc with the eyes of a newbie to this stuff and found some areas for clarification. In section 3, we mention "end-user" for the first time, without explaining what an end-user is in this context.. In our courses we have to make that explanation sooner than later, because different audiences read different things in the word ?end-user?. ? Can?t find ?end-user? in the current version. I think we used end-customer and the goal was always ?residential/household end-users? The abbreviation of CPE is nowhere explained or fully written. ? Right, some other documents use CE. Is the same (Customer Edge or Customer Premises Equipment). We can point here to the definition at RFC7084, because this document is being updated, so if we need to clarify that (don't think so is the case, right now, but just in case), we could take the opportunity to do so ... Can we provide a link to an explanation of the Neighbor Discovery exhaustion attack? ? RFC6583 maybe 3.1.3 where we mention ?This method may be seen as easier to implement, but it also brings some drawbacks such as difficulties with troubleshooting?, can we make it a bit more explicit by stating that link-local addresses don?t appear in a trace route, for example? ? Can write some text, of course ? 3.2.1 ?It should be remembered that some mechanisms use a default /48 prefix size ? Do we have examples? ? Yeah, users of tunnel brokers (some delegate /48), 6to4, ULA, all them use by default /48. 3.2.3. I would make ?There is a clear exception to this rule when assigning addresses in a cellular network. I n this case a /64 will need to be provided for each PDP context for cellular phones, whereas for LTE modems/routers it will still be necessary to choose a /48 or /56, in accordance with the aforementioned considerations.? the paragraph after ?assigning a /64 or smaller prefix is highly discouraged? ? Ok. 4. ?Static assignment means that a prefix is assigned to a customer (typically an AAA) ? What is an AAA? Try to explain abbreviations. ? I?m starting to think that the target of the document is not clear. AAA is something obvious for any network operator. The document doesn?t target end-users ? or I got something wrong? AAA -> Authentication, Authorization and Accounting 4.1 ?The easiest way method? remove way or method. ? Ok. 4.2 ?If the CPE knows that the delegated prefix has changed it should send out RA packets? Write Router Advertisements. ? Same as above, but we can write the complete text each time we use each abbreviation. Did the authors consider images to explain certain concepts? For example bit boundary? RIPE NCC can help with that, if you wish. ? I?m fine and happy with that support, but again, who is the target for the document? Need that target all this? I hope this input is useful. Thanks again! Nathalie K?nneke-Trenaman IPv6 Program Manager RIPE NCC On 27 Mar 2017, at 15:30, Jan Zorz - Go6 wrote: Dear RIPE BCOP community, 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 BCOP TF (here) to check if this is a real best operational practice and get consensus on it. We are also submitting this document to RIPE IPv6 WG to check the technical validity of the document and also get consensus on it. 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. From zorz at isoc.org Mon Apr 3 16:51:31 2017 From: zorz at isoc.org (Jan Zorz - ISOC) Date: Mon, 3 Apr 2017 16:51:31 +0200 Subject: [bcop] IPv6 prefix delegation BCOP document available for comments and suggestions In-Reply-To: References: <6a960c0d-1e78-7ab9-34b3-635b03a4d6e5@go6.si> <31E7EC4E-FF36-4F51-93CE-3ECBAAE8F45A@ripe.net> Message-ID: On 03/04/2017 16:40, Mikael Abrahamsson wrote: > On Mon, 3 Apr 2017, Nathalie Trenaman wrote: > >> the paragraph after ?assigning a /64 or smaller prefix is highly >> discouraged? > > Hi, > > I also like this document. I would put a reference somewhere to: > > https://www.broadband-forum.org/technical/download/TR-177.pdf > > "A delegated prefix for use within the home network (mandatory). The > Broadband Forum suggests a size for the delegated prefix of at least a > /60 for home network or SOHO environments, with a recommended prefix > length of /56. The delegated prefix may be extended to a /48 for larger > organizations." > > Just to at least say that /64 is defective, and all documents I have > read from organizations that write about this, says at least /60, most > recommend /56. Piling on that BBF agrees probably wouldn't hurt. Excellent suggestion, added, thnx!!! Cheers from Cameroon, Jan From nathalie at ripe.net Mon Apr 3 17:01:20 2017 From: nathalie at ripe.net (Nathalie Trenaman) Date: Mon, 3 Apr 2017 18:01:20 +0300 Subject: [bcop] IPv6 prefix delegation BCOP document available for comments and suggestions In-Reply-To: <7695C132-DF2D-42BA-95D7-7E8B6B1A4712@consulintel.es> References: <6a960c0d-1e78-7ab9-34b3-635b03a4d6e5@go6.si> <31E7EC4E-FF36-4F51-93CE-3ECBAAE8F45A@ripe.net> <7695C132-DF2D-42BA-95D7-7E8B6B1A4712@consulintel.es> Message-ID: <7413DAB3-9B0C-4593-BCA8-722AECEB15D7@ripe.net> Hi Jordi, > > Hi Jan, > > Great doc, and very readable. Thanks to all the authors for their input. > I went over the doc with the eyes of a newbie to this stuff and found some areas for clarification. > > In section 3, we mention "end-user" for the first time, without explaining what an end-user is in this context.. In our courses we have to make that explanation sooner than later, because different audiences read different things in the word ?end-user?. > > ? Can?t find ?end-user? in the current version. I think we used end-customer and the goal was always ?residential/household end-users? > > The abbreviation of CPE is nowhere explained or fully written. > > ? Right, some other documents use CE. Is the same (Customer Edge or Customer Premises Equipment). We can point here to the definition at RFC7084, because this document is being updated, so if we need to clarify that (don't think so is the case, right now, but just in case), we could take the opportunity to do so ? I talked to Jan, don?t think this is needed, if we explain the intended audience better. ?operators? was a bit too vague. By explaining that this document is for an entity/organisation that provides internet connectivity to residential and business customers, the problem is solved. > > Can we provide a link to an explanation of the Neighbor Discovery exhaustion attack? > > ? RFC6583 maybe > > 3.1.3 > where we mention ?This method may be seen as easier to implement, but it also brings some drawbacks such as difficulties with troubleshooting?, can we make it a bit more explicit by stating that link-local addresses don?t appear in a trace route, for example? > > ? Can write some text, of course ? Yes, Jan took care of that, I believe. > > 3.2.1 > ?It should be remembered that some mechanisms use a default /48 prefix size ? > Do we have examples? > ? Yeah, users of tunnel brokers (some delegate /48), 6to4, ULA, all them use by default /48. ULA is not recommended you wrote, 6to4 is on the way to be deprecated and tunnel brokers are not the intended audience of the doc, right? I would just leave this out?. > > 3.2.3. > I would make > > > ?There is a clear exception to this rule when assigning addresses in a cellular network. I n this case a /64 will need to be provided for each PDP context for cellular phones, whereas for LTE modems/routers it will still be necessary to choose a /48 or /56, in accordance with the aforementioned considerations.? > the paragraph after ?assigning a /64 or smaller prefix is highly discouraged? > > ? Ok. > > 4. > ?Static assignment means that a prefix is assigned to a customer (typically an AAA) ? > What is an AAA? Try to explain abbreviations. > ? I?m starting to think that the target of the document is not clear. AAA is something obvious for any network operator. The document doesn?t target end-users ? or I got something wrong? AAA -> Authentication, Authorization and Accounting The target audience was indeed not explained well at the beginning ;) > > 4.1 > ?The easiest way method? remove way or method. > ? Ok. > > 4.2 > ?If the CPE knows that the delegated prefix has changed it should send out RA packets? > Write Router Advertisements. > ? Same as above, but we can write the complete text each time we use each abbreviation. That is good practice in writing documentation, the first time write the word out full, later use the abbreviation. > > Did the authors consider images to explain certain concepts? For example bit boundary? RIPE NCC can help with that, if you wish. > > ? I?m fine and happy with that support, but again, who is the target for the document? Need that target all this? Like I said, don?t know. Wonder how the rest feels? Cheers, Nathalie From jan at go6.si Mon Apr 24 10:19:04 2017 From: jan at go6.si (Jan Zorz - Go6) Date: Mon, 24 Apr 2017 10:19:04 +0200 Subject: [bcop] BCOP TF meeting at RIPE74 in Budapest Message-ID: Dear BCOP community, In roughly two weeks we have a BCOP TF meeting in Budapest and we would like to ask if there are presentation proposals or new ideas for BCOP documents. If so, please send them to this list or the BCOP TF co-chairs (Benno and Jan) so we can put them on the agenda. See you all in Budapest, Jan