2018-02 Assignment Clarification in IPv6 Policy - comments from today meeting
Hi all, I've been asked to state what is the problem. I think it was clear in my slides, but anyway, here we go with all the problems I see: 1) The current policy text says "Providing another entity with separate addresses (not prefixes)". To me this is inconsistent addresses instead of an address vs not-prefixes. 2) If the end-device need a /64 instead of a single address, as per RFC8273, then it is breaking the actual policy. 3) If we allow sub-assignments, what is then the difference in between IPv6 PA and PI ? So, I think it is clear we have not just one problem? Now, if we want to go further. Do we have the same problem with IPv4 if, for example a university, instead of using NAT, they also sub-assign public IPv4 addresses to students? Inputs? Regards, Jordi ********************************************** 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 exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
On 16.05.2018 14:19, JORDI PALET MARTINEZ via address-policy-wg wrote:
Hi all,
I've been asked to state what is the problem.
I think it was clear in my slides, but anyway, here we go with all the problems I see:
1) The current policy text says "Providing another entity with separate addresses (not prefixes)". To me this is inconsistent addresses instead of an address vs not-prefixes.
I think I mentioned this on 2016-04 already; any single address is always a prefix as well, /128 in v6. But your slide 3 shows nicely why I strictly oppose more meddling with this paragraph. We went from 42 words in »2.6 Assign« to 98 in the current policy text, which your proposal would boost to a staggering 134 words. And that's without the necessary – but yet missing – definitions of »non-permanently« or what happens on links that are not »operated« by the assigment holder (i. e. a link a peer operates cannot use numbers from my assignment?). Not to mention the loophole that narrow band services are explicitely are allowed now — given 100 GBit/sec links are common these days, 10 to 100 MBit/sec is definitely narrow band today, right? But there is a point everyone seems to happily ignore: The text discussed last time, as well as this time, changes the basic definition of what an assignment is and "to assign" means. As such, that definition applies everywhere where the policy document talks about assignments. Like e. g. in »5.4.3. Assignment to operator's infrastructure«: »An organisation (i.e. ISP/LIR) may assign a network prefix per PoP as the service infrastructure of an IPv6 service operator. Each assignment to a PoP is regarded as one assignment regardless of the number of users using the PoP. A separate assignment can be obtained for the in-house operations of the operator.« The more text we put into 2.6, the more difficult it will become to not violate the policy, for End Users, ISPs and even for LIRs. Any change to "2.6 Assign" applies to PA and PI space alike.
3) If we allow sub-assignments, what is then the difference in between IPv6 PA and PI ?
You are barking at the wrong tree. "2.6 Assign" applies to PI and PA and disencourages sub-assignments (of any assigned space) "to other parties" anyway.
So, I think it is clear we have not just one problem?
I do not see a real problem with the text of ripe-699 – unless I start nit-picking and take the policy apart, word by word. If one *wants*, the *intention* of the policy can be understood. If one does not want to understand the intention, more words will simply make things worse, not better. Regards, -kai
Hi Kai, Below, in-line. Regards, Jordi -----Mensaje original----- De: address-policy-wg <address-policy-wg-bounces@ripe.net> en nombre de Kai 'wusel' Siering <wusel+ml@uu.org> Organización: Unseen University, Department of Magic Mails Fecha: miércoles, 16 de mayo de 2018, 16:47 Para: <address-policy-wg@ripe.net> Asunto: Re: [address-policy-wg] 2018-02 Assignment Clarification in IPv6 Policy - comments from today meeting On 16.05.2018 14:19, JORDI PALET MARTINEZ via address-policy-wg wrote: > Hi all, > > I've been asked to state what is the problem. > > I think it was clear in my slides, but anyway, here we go with all the problems I see: > > 1) The current policy text says "Providing another entity with separate addresses (not prefixes)". > To me this is inconsistent addresses instead of an address vs not-prefixes. I think I mentioned this on 2016-04 already; any single address is always a prefix as well, /128 in v6. So, to make sure I understood your point. You think that a single /128 prefix is ok to be sub-assigned (as per the current policy), but a single /64 prefix is not? Or you will agree in a change that only fix that? But your slide 3 shows nicely why I strictly oppose more meddling with this paragraph. We went from 42 words in »2.6 Assign« to 98 in the current policy text, which your proposal would boost to a staggering 134 words. And that's without the necessary – but yet missing – definitions of »non-permanently« or what happens on links that are not »operated« by the assigment holder (i. e. a link a peer operates cannot use numbers from my assignment?). Not to mention the loophole that narrow band services are explicitely are allowed now — given 100 GBit/sec links are common these days, 10 to 100 MBit/sec is definitely narrow band today, right? Regarding the specific wording, you're totally right and we should decide *if* there is a way to re-formulate it. But there is a point everyone seems to happily ignore: The text discussed last time, as well as this time, changes the basic definition of what an assignment is and "to assign" means. As such, that definition applies everywhere where the policy document talks about assignments. Like e. g. in »5.4.3. Assignment to operator's infrastructure«: »An organisation (i.e. ISP/LIR) may assign a network prefix per PoP as the service infrastructure of an IPv6 service operator. Each assignment to a PoP is regarded as one assignment regardless of the number of users using the PoP. A separate assignment can be obtained for the in-house operations of the operator.« That's the reason I initially suggested, even when discussing 2016-04, that the text should be only in the IPv6 PI section ... the consensus was in the other direction. The more text we put into 2.6, the more difficult it will become to not violate the policy, for End Users, ISPs and even for LIRs. Any change to "2.6 Assign" applies to PA and PI space alike. > 3) If we allow sub-assignments, what is then the difference in between IPv6 PA and PI ? You are barking at the wrong tree. "2.6 Assign" applies to PI and PA and disencourages sub-assignments (of any assigned space) "to other parties" anyway. > So, I think it is clear we have not just one problem? I do not see a real problem with the text of ripe-699 – unless I start nit-picking and take the policy apart, word by word. If one *wants*, the *intention* of the policy can be understood. If one does not want to understand the intention, more words will simply make things worse, not better. This is the big problem in my opinion, and I actually forgot the mention it before. I think policy must be as much as possible, a text which has only one interpretation, even if that means it is longer. Otherwise, and I explained this in emails when discussing 2016-04, people that "follows" the policy process has advantage in terms of interpretation vs a newcomer that will read only the *policy text*, but not the impact analysis, and all the discussions used to clarify the policy text. Regards, -kai ********************************************** 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 exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
Hi there, on 16.05.2018 17:33, JORDI PALET MARTINEZ via address-policy-wg wrote:
So, to make sure I understood your point. You think that a single /128 prefix is ok to be sub-assigned (as per the current policy), but a single /64 prefix is not? Or you will agree in a change that only fix that?
I think that the current text serves it's purpose and _can_ be understood in the way it was intended to (i. e. countering the, non-standard, RIPE NCC idea that using SLAAC or DHCPv6 constitutes an act of sub-assigning addresses, forbidden as per section 2.6). If you read it while suffering from an overdose of technical writings, a normal reaction could be "R U kidding me? Addresses, even plural, but not prefixes — does not compute". I do *not* agree that _that paragraph_ needs another band-aid. I think that rough consensus should be sought on what uses by the assignment holder of assigned IPv6 space are considered ok. Afterwards, amending the policy at least should be more easy — if still considered necessary by then.
Regarding the specific wording, you're totally right and we should decide *if* there is a way to re-formulate it.
I think we should keep it as it is, take a step back and consider what issue, if any, there is. Frankly, I do not see one ATM; policy texts should not try to micromanage the readers mind, IMO.
That's the reason I initially suggested, even when discussing 2016-04, that the text should be only in the IPv6 PI section ... the consensus was in the other direction.
Well, the current policy does allow »minor« third-party-usage for any (note the word) assigned IPv6 space. Previously, adopting RIPE NCCs view on SLAAC being an act of address assignment, no-one was allowed to run a Guest WiFi or similar with RIPE area assigned IPv6 space, PA or PI — as sub-assignments were (and are) forbidden and providing a third party with single addresses out of an assignment holder's addresses constituted a sub-assignment according to RIPE NCC (this is now fixed per policy in ripe-699's section 2.6). So, if you agree with RIPE NCCs view, 2.6 is the correct location. If not, the policy maybe was fine and the issue lay elsewhere.
This is the big problem in my opinion, and I actually forgot the mention it before. I think policy must be as much as possible, a text which has only one interpretation, even if that means it is longer. Otherwise, and I explained this in emails when discussing 2016-04, people that "follows" the policy process has advantage in terms of interpretation vs a newcomer that will read only the *policy text*, but not the impact analysis, and all the discussions used to clarify the policy text.
I totally disagree with you on this. The more words go into a policy, the more loopholes are opened, which then have to backfill with new wordings, leading to pages after pages of policy text. A policy text should be easy to understand (especially for non-native speakers of the english language ;)), give a guideline on what use case it expects to cover and at all costs refrain from giving examples. The thing with examples is that, from my experience, they invite people to game the rules. Please don't overengineer the policies. Regards, -kai
Hi Kai, Responding below, in-line. Regards, Jordi -----Mensaje original----- De: address-policy-wg <address-policy-wg-bounces@ripe.net> en nombre de Kai 'wusel' Siering <wusel+ml@uu.org> Organización: Unseen University, Department of Magic Mails Fecha: miércoles, 16 de mayo de 2018, 20:37 Para: <address-policy-wg@ripe.net> Asunto: [address-policy-wg] 2018-02 Assignment Clarification in IPv6 Policy - comments from today meeting Hi there, on 16.05.2018 17:33, JORDI PALET MARTINEZ via address-policy-wg wrote: > So, to make sure I understood your point. You think that a single /128 prefix is ok to be sub-assigned (as per the current policy), but a single /64 prefix is not? > Or you will agree in a change that only fix that? I think that the current text serves it's purpose and _can_ be understood in the way it was intended to (i. e. countering the, non-standard, RIPE NCC idea that using SLAAC or DHCPv6 constitutes an act of sub-assigning addresses, forbidden as per section 2.6). [Jordi] So there is a contradiction here, because according you, only if you use manual setup, then it will not be a sub-assignment? If you read it while suffering from an overdose of technical writings, a normal reaction could be "R U kidding me? Addresses, even plural, but not prefixes — does not compute". I do *not* agree that _that paragraph_ needs another band-aid. [Jordi] The fact that you and I are interpreting different things, shows clearly, that the text is not good. I think that rough consensus should be sought on what uses by the assignment holder of assigned IPv6 space are considered ok. Afterwards, amending the policy at least should be more easy — if still considered necessary by then. > Regarding the specific wording, you're totally right and we should decide *if* there is a way to re-formulate it. I think we should keep it as it is, take a step back and consider what issue, if any, there is. Frankly, I do not see one ATM; policy texts should not try to micromanage the readers mind, IMO. > That's the reason I initially suggested, even when discussing 2016-04, that the text should be only in the IPv6 PI section ... the consensus was in the other direction. Well, the current policy does allow »minor« third-party-usage for any (note the word) assigned IPv6 space. Previously, adopting RIPE NCCs view on SLAAC being an act of address assignment, no-one was allowed to run a Guest WiFi or similar with RIPE area assigned IPv6 space, PA or PI — as sub-assignments were (and are) forbidden and providing a third party with single addresses out of an assignment holder's addresses constituted a sub-assignment according to RIPE NCC (this is now fixed per policy in ripe-699's section 2.6). So, if you agree with RIPE NCCs view, 2.6 is the correct location. If not, the policy maybe was fine and the issue lay elsewhere. [Jordi] Again, then because I'm using latest standards which allow me to use /64 per hosts, it means I can't use it. We have moved the limit to a single address while it was NONE. The community can decide then to move to a single prefix, or why not, later to several /64 prefixes ... Thinks about that please. > This is the big problem in my opinion, and I actually forgot the mention it before. I think policy must be as much as possible, a text which has only one interpretation, even if that means it is longer. Otherwise, and I explained this in emails when discussing 2016-04, people that "follows" the policy process has advantage in terms of interpretation vs a newcomer that will read only the *policy text*, but not the impact analysis, and all the discussions used to clarify the policy text. I totally disagree with you on this. The more words go into a policy, the more loopholes are opened, which then have to backfill with new wordings, leading to pages after pages of policy text. A policy text should be easy to understand (especially for non-native speakers of the english language ;)), give a guideline on what use case it expects to cover and at all costs refrain from giving examples. The thing with examples is that, from my experience, they invite people to game the rules. [Jordi] Again, newcomers have a disadvantage if the policy text is not clear enough and provides different interpretations vs the impact analysis, because the impact analysis is not *referenced* at the policy manual with every policy change (which will be way to complex). Please don't overengineer the policies. [Jordi] On the other way around, I'm trying to make sure that 1) the text is more clear or 2) we simplify all the mess by removing IPv6 PI Regards, -kai ********************************************** 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 exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
participants (2)
-
JORDI PALET MARTINEZ -
Kai 'wusel' Siering