IPv6 Prefix delegation BCOP version 3 is out...
Dear RIPE IPv6 WG, After presentation at RIPE74 BCOP TF and IPv6 WG sessions we got some feedback from community over mailing list and while on stage and we addressed those comments as far as we could, resulting in version 3 of the IPv6 prefix delegations draft. To avoid sending around emails with attachment I'm providing the link where you can access the PDF file: https://www.sinog.si/docs/draft-IPv6pd-BCOP-v3.pdf I have a feeling that after all this cycles and comments from the community - we are reaching the point when we'll have to consider calling a consensus if possible, make it a stable RIPE BCOP document and give it a number. Please, read the latest version and see if you can agree with the current text and express your support (if agree) on this mailing list, so chairs can judge if there is enough consensus on the text to maybe go into a WG last call (or maybe even skip that if clear consensus, this is not PDP process ;) ) Cheers and thnx, Jan (on behalf of the co-authors of the document)
Hi, thanks for the effort put into this document. I have two bugreports: In section 4.1.1:
If we decide to use /127 for each point to point link, then it is also advisable to allocate a /64 for each link and use just one /127 out of it to prevent the Neighbor Discovery exhaustion attack (RFC6583).
My understanding of this sentence is that allocating /64 somehow prevents Neighbor Discovery exhaustion attack. It could be solved by splitting those two pieces of information into two separate sentences:
Using /127 for each point to point link can, on the other hand, prevent the Neighbor Discovery exhaustion attack (RFC6583). To avoid possible renumbering in the future, it is always advisable to allocate a /64 for each link and use just one /127 out of it.
In section 5.1:
Bear in mind that end customers with an IPv4 subnet behind their CPE never got “non-persistent” assigned IPv4 prefixes as this would require reconfiguration of all hosts on their network every few hours or days. By contrast, every IPv6 customer gets an IPv6 subnet so it is unnecessary to apply this “IPv4 model” to IPv6.
I don't really understand the last sentence. Which "IPv4 model" is unnecessary to apply to IPv6? The model of static leases? I would propose something like:
By contrast, every IPv6 customer gets an IPv6 subnet, so keeping customer's IPv6 subnet persistent follows perfectly the "IPv4 model".
Cheers, -- Ondřej Caletka CESNET
Hi Ondrej, I agree with our first proposed change. However, I think you didn’t got the other one. The IPv4 model is NAT, so the addresses inside the customer network aren’t affected by non-persistent CPE WAN addressing, because internally is not “seen”. Regards, Jordi -----Mensaje original----- De: ipv6-wg <ipv6-wg-bounces@ripe.net> en nombre de Ondřej Caletka <Ondrej.Caletka@cesnet.cz> Responder a: <Ondrej.Caletka@cesnet.cz> Fecha: miércoles, 28 de junio de 2017, 16:42 Para: <ipv6-wg@ripe.net> Asunto: Re: [ipv6-wg] IPv6 Prefix delegation BCOP version 3 is out... Hi, thanks for the effort put into this document. I have two bugreports: In section 4.1.1: > If we decide to use /127 for each point to point link, then it is also advisable to > allocate a /64 for each link and use just one /127 out of it to prevent the Neighbor Discovery > exhaustion attack (RFC6583). My understanding of this sentence is that allocating /64 somehow prevents Neighbor Discovery exhaustion attack. It could be solved by splitting those two pieces of information into two separate sentences: > Using /127 for each point to point link can, on the other hand, prevent the Neighbor Discovery exhaustion attack (RFC6583). > To avoid possible renumbering in the future, it is always advisable to allocate a /64 for each link and use just one /127 out of it. In section 5.1: > Bear in mind that end customers with an IPv4 subnet behind their CPE never got > “non-persistent” assigned IPv4 prefixes as this would require reconfiguration of all hosts on > their network every few hours or days. By contrast, every IPv6 customer gets an IPv6 subnet > so it is unnecessary to apply this “IPv4 model” to IPv6. I don't really understand the last sentence. Which "IPv4 model" is unnecessary to apply to IPv6? The model of static leases? I would propose something like: > > By contrast, every IPv6 customer gets an IPv6 subnet, so keeping customer's IPv6 subnet persistent follows perfectly the "IPv4 model". Cheers, -- Ondřej Caletka CESNET ********************************************** 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.
On 28/06/2017 17:20, JORDI PALET MARTINEZ wrote:
Hi Ondrej,
I agree with our first proposed change.
However, I think you didn’t got the other one. The IPv4 model is NAT, so the addresses inside the customer network aren’t affected by non-persistent CPE WAN addressing, because internally is not “seen”.
Jordi, Ondrej is right. That sentence reads as that we are applying the "IPv4 prefix delegation" model to IPv6. Now, or we do it as Ondrej suggested (I like his proposal), or we make sure that "IPv4 model" says that that is a NAT model - and maybe even add Ondrej's suggestion as an additional information. Cheers, Jan
Regards, Jordi
-----Mensaje original----- De: ipv6-wg <ipv6-wg-bounces@ripe.net> en nombre de Ondřej Caletka <Ondrej.Caletka@cesnet.cz> Responder a: <Ondrej.Caletka@cesnet.cz> Fecha: miércoles, 28 de junio de 2017, 16:42 Para: <ipv6-wg@ripe.net> Asunto: Re: [ipv6-wg] IPv6 Prefix delegation BCOP version 3 is out...
Hi,
thanks for the effort put into this document. I have two bugreports:
In section 4.1.1:
If we decide to use /127 for each point to point link, then it is also advisable to allocate a /64 for each link and use just one /127 out of it to prevent the Neighbor Discovery exhaustion attack (RFC6583).
My understanding of this sentence is that allocating /64 somehow prevents Neighbor Discovery exhaustion attack.
It could be solved by splitting those two pieces of information into two separate sentences:
Using /127 for each point to point link can, on the other hand, prevent the Neighbor Discovery exhaustion attack (RFC6583). To avoid possible renumbering in the future, it is always advisable to allocate a /64 for each link and use just one /127 out of it.
In section 5.1:
Bear in mind that end customers with an IPv4 subnet behind their CPE never got “non-persistent” assigned IPv4 prefixes as this would require reconfiguration of all hosts on their network every few hours or days. By contrast, every IPv6 customer gets an IPv6 subnet so it is unnecessary to apply this “IPv4 model” to IPv6.
I don't really understand the last sentence. Which "IPv4 model" is unnecessary to apply to IPv6? The model of static leases?
I would propose something like:
By contrast, every IPv6 customer gets an IPv6 subnet, so keeping customer's IPv6 subnet persistent follows perfectly the "IPv4 model".
Cheers,
-- Ondřej Caletka CESNET
********************************************** 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.
On 28/06/2017 16:42, Ondřej Caletka wrote:
Hi,
thanks for the effort put into this document. I have two bugreports:
Hey, Thnx for having a look! :)
In section 4.1.1:
If we decide to use /127 for each point to point link, then it is also advisable to allocate a /64 for each link and use just one /127 out of it to prevent the Neighbor Discovery exhaustion attack (RFC6583).
My understanding of this sentence is that allocating /64 somehow prevents Neighbor Discovery exhaustion attack.
Nope. Using /127 or /126 prevents the attack. Allocating /64 for each /127 or /126 just makes it harder to sweep over several links and burn the ND anyway if all those subnets are connected to the same router. On the other hand, it's sane to allocate /64 for each link also out of easier administration purposes.
It could be solved by splitting those two pieces of information into two separate sentences:
Agree. That improves readability. Thnx!
Using /127 for each point to point link can, on the other hand, prevent the Neighbor Discovery exhaustion attack (RFC6583). To avoid possible renumbering in the future, it is always advisable to allocate a /64 for each link and use just one /127 out of it.
In section 5.1:
Bear in mind that end customers with an IPv4 subnet behind their CPE never got “non-persistent” assigned IPv4 prefixes as this would require reconfiguration of all hosts on their network every few hours or days. By contrast, every IPv6 customer gets an IPv6 subnet so it is unnecessary to apply this “IPv4 model” to IPv6.
I don't really understand the last sentence. Which "IPv4 model" is unnecessary to apply to IPv6? The model of static leases?
I would propose something like:
By contrast, every IPv6 customer gets an IPv6 subnet, so keeping customer's IPv6 subnet persistent follows perfectly the "IPv4 model".
Agree. Look like we are heading for draft v.4 ;) Let's collect more feedback and then fix the text... Cheers and tnnx, Jan
Cheers,
-- Ondřej Caletka CESNET
Hello Jan, all, Dne 28.6.2017 v 17:23 Jan Zorz - Go6 napsal(a):
Agree. Look like we are heading for draft v.4 ;)
Let's collect more feedback and then fix the text...
I have an amendment idea that I partially think it may have its place in the document. The thing is, many ISPs don't really understand the difference between resources (sub-)allocation and assignment. ISPs that are also LIRs just know they cannot assign more than /48 to a customer (end-site, to be precise ;) ). But if their customer is a small non-LIR ISP, who is requesting IP addresses for deploying IPv6 to its clients, they should not give them an assignment of shorter prefix but rather a suballocation or a aggregated assignment. If the small ISP only gets assigned /48 and tries to divide it to its customers, then not only is there little room for assigning "at least /56 to each customer" but it also is breaking the RIPE IPv6 policy by sub-assigning assignments. This is quite different situation from the IPv4 scenario, where small non-LIR ISP typically employ CGN, where it's completely valid to just use IP addresses assigned to the ISP itself. I already got a few questions concerning this topic. The questions are: 1. Is this topic important enough to be in this document? 2. Is this something RIPE-specific or is the situation in other RIRs similar? If you think it's worth it, I can try to draft some text around this topic. -- Ondřej Caletka CESNET
Hi Ondrej, I think you somehow answered yourself. It is non-acceptable usage (according policy), and not just in RIPE but also the other RIRs. Also, and ISP/LIR will never get a /48, so I don’t see the case. If an ISP applies for an end-user prefix, again, they will break the policy. So in my opinion, this is out of the scope of this document. Let’s see if there are opinions on this … Regards, Jordi -----Mensaje original----- De: ipv6-wg <ipv6-wg-bounces@ripe.net> en nombre de Ondřej Caletka <Ondrej.Caletka@cesnet.cz> Responder a: <Ondrej.Caletka@cesnet.cz> Fecha: lunes, 3 de julio de 2017, 16:33 Para: <ipv6-wg@ripe.net> Asunto: Re: [ipv6-wg] IPv6 Prefix delegation BCOP version 3 is out... Hello Jan, all, Dne 28.6.2017 v 17:23 Jan Zorz - Go6 napsal(a): > Agree. Look like we are heading for draft v.4 ;) > > Let's collect more feedback and then fix the text... I have an amendment idea that I partially think it may have its place in the document. The thing is, many ISPs don't really understand the difference between resources (sub-)allocation and assignment. ISPs that are also LIRs just know they cannot assign more than /48 to a customer (end-site, to be precise ;) ). But if their customer is a small non-LIR ISP, who is requesting IP addresses for deploying IPv6 to its clients, they should not give them an assignment of shorter prefix but rather a suballocation or a aggregated assignment. If the small ISP only gets assigned /48 and tries to divide it to its customers, then not only is there little room for assigning "at least /56 to each customer" but it also is breaking the RIPE IPv6 policy by sub-assigning assignments. This is quite different situation from the IPv4 scenario, where small non-LIR ISP typically employ CGN, where it's completely valid to just use IP addresses assigned to the ISP itself. I already got a few questions concerning this topic. The questions are: 1. Is this topic important enough to be in this document? 2. Is this something RIPE-specific or is the situation in other RIRs similar? If you think it's worth it, I can try to draft some text around this topic. -- Ondřej Caletka CESNET ********************************************** 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.
Hi, On Tue, Jul 04, 2017 at 03:20:58PM +0200, JORDI PALET MARTINEZ wrote:
I think you somehow answered yourself. It is non-acceptable usage (according policy), and not just in RIPE but also the other RIRs.
Huh, what? Sub-allocations are perfectly fine according to RIPE policy, and initially for all other RIRs (as that was part of the very first IPv6 policy document). So if you have an ISP customer that has no own LIR, sub-allocating a /40 to them so they can give their customers /48s is the thing to do. (But indeed, it's out of scope of this document which is really focused on end user assignments) Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
You’re right, if you assume that a LIR got a /48 from a RIR, but this is not normal, right? What I read from that is that the an ISP is getting and end-user /48, as is the only way to get a /48, at least in a normal situation, right? Regards, Jordi -----Mensaje original----- De: ipv6-wg <ipv6-wg-bounces@ripe.net> en nombre de Gert Doering <gert@space.net> Responder a: <gert@space.net> Fecha: martes, 4 de julio de 2017, 17:21 Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es> CC: <ipv6-wg@ripe.net> Asunto: Re: [ipv6-wg] IPv6 Prefix delegation BCOP version 3 is out... Hi, On Tue, Jul 04, 2017 at 03:20:58PM +0200, JORDI PALET MARTINEZ wrote: > I think you somehow answered yourself. It is non-acceptable usage (according policy), and not just in RIPE but also the other RIRs. Huh, what? Sub-allocations are perfectly fine according to RIPE policy, and initially for all other RIRs (as that was part of the very first IPv6 policy document). So if you have an ISP customer that has no own LIR, sub-allocating a /40 to them so they can give their customers /48s is the thing to do. (But indeed, it's out of scope of this document which is really focused on end user assignments) Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ********************************************** 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.
Hi,
You’re right, if you assume that a LIR got a /48 from a RIR, but this is not normal, right?
What I read from that is that the an ISP is getting and end-user /48, as is the only way to get a /48, at least in a normal situation, right?
An LIR will not get PA addresses smaller than a /32 from RIPE NCC, that is true. /32 is the minimum allocation size for IPv6 PA. An LIR might however get a sub-allocation from a different LIR. There is no minimum sub-allocation size, so it might be a /48. In most cases it wouldn't be wise to sub-allocate such a small block, but it is allowed. I could imagine something like that if for example a non-LIR was running a small hosting business where they want to assign a /56 to each customer. They could get a /48 sub-allocation from an LIR, from which they could make the /56 assignments to their customers. I still would recommend sub-allocating and assigning larger prefixes, but this is just an example. :) Cheers! Sander
Hi,
Also, and ISP/LIR will never get a /48
Euhm, not technically true. An LIR can ask for a PI assignment (see https://www.ripe.net/publications/docs/ripe-684#IPv6_PI_Assignments_LIR). Not relevant for this document as you and Gert pointed out, just stating this for the archives :) Cheers! Sander
On Tue, Jul 4, 2017, at 15:20, JORDI PALET MARTINEZ wrote:
Also, and ISP/LIR will never get a /48, so I don’t see the case. If an ISP applies for an end-user prefix, again, they will break the policy.
Hi, You should be aware that ISPs do not start directly as big companies. Some small local ISPs do not consider to be a good "investment" to become LIR from day 0, so they don't. They start with a small *assignment* (not very often a sub-allocation) from the upstream provider (yes they start with only one upstream !!!!) with the same story applying on both v4 and v6. There are more ISPs start start(ed) like this than ISPs that became LIR from day 0. I will not discuss the problems that such a strategy pose later in the lifetime of such an ISP, but this is the reality in many cases. Weather this situation should be treated in the document - not sure. However having a mention that this is not how things are supposed to happen would be a good idea. -- Radu-Adrian FEURDEAN
Hi Radu,
You should be aware that ISPs do not start directly as big companies. Some small local ISPs do not consider to be a good "investment" to become LIR from day 0, so they don't. They start with a small *assignment* (not very often a sub-allocation) from the upstream provider
[...]
Weather this situation should be treated in the document - not sure. However having a mention that this is not how things are supposed to happen would be a good idea.
I think this would indeed be a good place to recommend against this, but maybe the other way around: "When providing address space to a smaller ISP you should give them a sub-allocation (not an assignment) that allows them to make properly sized (see the rest of this BCOP) assignments to their customers." or something like that. Cheers! Sander
Hi, On Wed, Jul 05, 2017 at 10:11:12AM +0200, Sander Steffann wrote:
I think this would indeed be a good place to recommend against this, but maybe the other way around: "When providing address space to a smaller ISP you should give them a sub-allocation (not an assignment) that allows them to make properly sized (see the rest of this BCOP) assignments to their customers." or something like that.
+1 Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
On 5 Jul 2017, at 09:21, Gert Doering <gert@space.net> wrote:
Hi,
On Wed, Jul 05, 2017 at 10:11:12AM +0200, Sander Steffann wrote:
I think this would indeed be a good place to recommend against this, but maybe the other way around: "When providing address space to a smaller ISP you should give them a sub-allocation (not an assignment) that allows them to make properly sized (see the rest of this BCOP) assignments to their customers." or something like that.
+1
Yes, that’s the important bottom line. Tim
Dne 5.7.2017 v 10:11 Sander Steffann napsal(a):
I think this would indeed be a good place to recommend against this, but maybe the other way around: "When providing address space to a smaller ISP you should give them a sub-allocation (not an assignment) that allows them to make properly sized (see the rest of this BCOP) assignments to their customers." or something like that.
Exactly, that was what I meant, just a reminder that there is this difference between assignment and allocation. Even though it's the first topic at every RIPE NCC training, there are lots of LIRs ignoring such trainings and even more non-LIR ISPs who don't even have chance to learn that. I think this small paragraph could fit to the end of section 4:
Please also note that RIRs require proper registration of prefixes assigned to the customers. Unlike typical IPv4 scenario with one address per customer or even Carrier Grade NAT, it is not possible to assign addresses to the customers out of the prefixes assigned to ISP's infrastructure. As assigned prefixes cannot be sub-assigned, an operator always need an allocation, not an assignment.
I'm aware that this is not complete information for a total newcomer, but it has at least the right keyword, which can be either Googled or discussed with the upstream LIR. -- Cheers, Ondřej Caletka
On 05/07/2017 10:11, Sander Steffann wrote:
Hi Radu,
You should be aware that ISPs do not start directly as big companies. Some small local ISPs do not consider to be a good "investment" to become LIR from day 0, so they don't. They start with a small *assignment* (not very often a sub-allocation) from the upstream provider
[...]
Weather this situation should be treated in the document - not sure. However having a mention that this is not how things are supposed to happen would be a good idea.
I think this would indeed be a good place to recommend against this, but maybe the other way around: "When providing address space to a smaller ISP you should give them a sub-allocation (not an assignment) that allows them to make properly sized (see the rest of this BCOP) assignments to their customers." or something like that.
+1. I introduced this text into section 4.1.5 and here comes the BCOP draft v.4 ;) https://www.sinog.si/docs/draft-IPv6pd-BCOP-v4.pdf Can you please all have a look if this document is now ready for publication? We are receiving many requests for a stable document on this topic - and we've been "babysitting" this one quite long enough. So, my question is - should we publish it as a stable RIPE BCP document? Cheers and thnx, Jan
Hi all,
I introduced this text into section 4.1.5 and here comes the BCOP draft v.4 ;)
https://www.sinog.si/docs/draft-IPv6pd-BCOP-v4.pdf
Can you please all have a look if this document is now ready for publication? We are receiving many requests for a stable document on this topic - and we've been "babysitting" this one quite long enough.
So, my question is - should we publish it as a stable RIPE BCP document?
Cheers and thnx, Jan
Yes please! Thanks, Nathalie
+1 — Sebastian Becker sb@lab.dtag.de
Am 26.07.2017 um 15:30 schrieb Nathalie Trenaman <nathalie@ripe.net>:
Hi all,
I introduced this text into section 4.1.5 and here comes the BCOP draft v.4 ;)
https://www.sinog.si/docs/draft-IPv6pd-BCOP-v4.pdf
Can you please all have a look if this document is now ready for publication? We are receiving many requests for a stable document on this topic - and we've been "babysitting" this one quite long enough.
So, my question is - should we publish it as a stable RIPE BCP document?
Cheers and thnx, Jan
Yes please!
Thanks, Nathalie
Dne 26.7.2017 v 13:18 Jan Zorz - Go6 napsal(a):
I introduced this text into section 4.1.5 and here comes the BCOP draft v.4 ;)
https://www.sinog.si/docs/draft-IPv6pd-BCOP-v4.pdf
Can you please all have a look if this document is now ready for publication? We are receiving many requests for a stable document on this topic - and we've been "babysitting" this one quite long enough.
Hello, sorry for another babysitting issue, but I still don't like this formulation in section 4.1.1:
If we decide to use /127 for each point to point link, then it is also advisable to allocate a /64 for each link and use just one /127 out of it to prevent the Neighbor Discovery exhaustion attack (RFC6583).
Let me try to rephrase this paragraph:
Some operators also use /126, /127, /112 or an alternative prefix assignment instead of /64 for managed links where addresses on the link are manually configured, and according to RFC6164, a /127 is suggested, to prevent, among others, the Neighbor Discovery exhaustion attack (RFC6583). Please note, that not all equipment currently supports this option, so /64 is still the safest approach and has the advantage of being future proof in the event that new standards make usage of the other 64 bits for other purposes or the link becomes point-to-multipoint, etc. Furthermore, some ISP hardware has limitations in using prefixes longer than /64, so the use of non-/64 prefixes will use more resources on these devices. If we decide to use /127 for each point to point link, then it is also advisable to allocate a /64 for each link and use just one /127 out of it.
Other than that, I found no more issues. PS: I also noticed that https://www.sinog.si has an invalid TLSA record ;) -- Ondřej Caletka
This highlighted something for me…
If we decide to use /127 for each point to point link, then it is also advisable to allocate a /64 for each link and use just one /127 out of it to prevent the Neighbor Discovery exhaustion attack (RFC6583).
The document could do with a pass by a good copy-editor (“we” is probably not the right language for a BCP). Is that something ISOC could arrange if you’re facilitating the BCOPs? :-) Cheers, Rob
On 27/07/2017 17:58, Rob Evans wrote:
This highlighted something for me…
If we decide to use /127 for each point to point link, then it is also advisable to allocate a /64 for each link and use just one /127 out of it to prevent the Neighbor Discovery exhaustion attack (RFC6583).
The document could do with a pass by a good copy-editor (“we” is probably not the right language for a BCP). Is that something ISOC could arrange if you’re facilitating the BCOPs? :-)
Hey, Thnx for this comment. Usually (RIPE-501, 554, 631) RIPE NCC staff does the language check and fine-tunes the grammar before publishing the document (and we are more than grateful for that ;) ) I hope that this will be true also in this case... Cheers and thnx, Jan
Hi all,
The document could do with a pass by a good copy-editor (“we” is probably not the right language for a BCP). Is that something ISOC could arrange if you’re facilitating the BCOPs? :-)
Hey,
Thnx for this comment. Usually (RIPE-501, 554, 631) RIPE NCC staff does the language check and fine-tunes the grammar before publishing the document (and we are more than grateful for that ;) )
I hope that this will be true also in this case...
Cheers and thnx, Jan
Absolutely! I'll pick this up with our communication team as soon as we have a document with consensus. Cheers, Nathalie
On 27/07/2017 17:49, Ondřej Caletka wrote:
Let me try to rephrase this paragraph:
Some operators also use /126, /127, /112 or an alternative prefix assignment instead of /64 for managed links where addresses on the link are manually configured, and according to RFC6164, a /127 is suggested, to prevent, among others, the Neighbor Discovery exhaustion attack (RFC6583). Please note, that not all equipment currently supports this option, so /64 is still the safest approach and has the advantage of being future proof in the event that new standards make usage of the other 64 bits for other purposes or the link becomes point-to-multipoint, etc. Furthermore, some ISP hardware has limitations in using prefixes longer than /64, so the use of non-/64 prefixes will use more resources on these devices. If we decide to use /127 for each point to point link, then it is also advisable to allocate a /64 for each link and use just one /127 out of it.
Hi, Thnx for this add-on. I fixed the text and here it goes the v.5 (hopefully the last one, if the stars are positioned properly ;) ) https://www.sinog.si/docs/draft-IPv6pd-BCOP-v5.pdf
Other than that, I found no more issues.
PS: I also noticed that https://www.sinog.si has an invalid TLSA record ;)
Thnx for pointing this out. It was not the TLSA taht was broken, it was my dnssec signer that played some tricks, but on that domain only. Go-figure ;) It should be fixed now. Cheers and thnx, Jan
Hi all, Looks good to me. +1 for going stable Nathalie Künneke-Trenaman IPv6 Program Manager RIPE NCC
On 27 Jun 2017, at 12:42, Jan Zorz - Go6 <jan@go6.si> wrote:
Dear RIPE IPv6 WG,
After presentation at RIPE74 BCOP TF and IPv6 WG sessions we got some feedback from community over mailing list and while on stage and we addressed those comments as far as we could, resulting in version 3 of the IPv6 prefix delegations draft.
To avoid sending around emails with attachment I'm providing the link where you can access the PDF file:
https://www.sinog.si/docs/draft-IPv6pd-BCOP-v3.pdf
I have a feeling that after all this cycles and comments from the community - we are reaching the point when we'll have to consider calling a consensus if possible, make it a stable RIPE BCOP document and give it a number.
Please, read the latest version and see if you can agree with the current text and express your support (if agree) on this mailing list, so chairs can judge if there is enough consensus on the text to maybe go into a WG last call (or maybe even skip that if clear consensus, this is not PDP process ;) )
Cheers and thnx, Jan (on behalf of the co-authors of the document)
participants (11)
-
Gert Doering -
Jan Zorz - Go6 -
JORDI PALET MARTINEZ -
Nathalie Trenaman -
ntrenaman -
Ondřej Caletka -
Radu-Adrian FEURDEAN -
Rob Evans -
Sander Steffann -
Sebastian Becker -
Tim Chown