Re: [sig-policy] prop-124-v006: Clarification on Sub-Assignments
Hi Satoru, Thanks for investing time in the several policy proposals. I think that the last couple of emails could help all you to better understand the problem. Clearly, if different people read the current policy text in a different way, it will be much better to find a way so we have a single and unique "reading" and no different ways to interpret it. Right? Regards, Jordi @jordipalet El 2/9/19 17:37, "Satoru Tsurumaki" escribió: Dear Colleagues, I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team. I would like to share a feedback in our community for prop-124,based on a meeting we organized on 21th Aug to discuss these proposals. Many participants expressed a neutral for the proposal with reasons that the problem in the current policy is something vague. Best Regards, Satoru Tsurumaki JPOPF-ST 2019年8月10日(土) 23:33 Sumon Ahmed Sabir : > > Dear SIG members > > A new version of the proposal "prop-124: Clarification on Sub-Assignments" > has been sent to the Policy SIG for review. > > It will be presented at the Open Policy Meeting at APNIC 48 in > Chiang Mai, Thailand on Thursday, 12 September 2019. > > Information about earlier versions is available from: > https://www.apnic.net/community/policy/proposals/prop-124 > > You are encouraged to express your views on the proposal: > > - Do you support or oppose the proposal? > - Is there anything in the proposal that is not clear? > - What changes could be made to this proposal to make it more effective? > > Please find the text of the proposal below. > > Kind Regards, > > Sumon, Bertrand, Ching-Heng > APNIC Policy SIG Chairs > > > -- > > prop-124-v006: Clarification on Sub-Assignments > > -- > > Proposer: Jordi Palet Martínez >jordi.pa...@theipv6company.com > > > 1. Problem Statement > > > Note that this proposal is ONLY relevant when end-users obtain direct > assignments > from APNIC, or when a LIR obtains, also from APNIC, and assignment for > exclusive > use within its infrastructure. Consequently this is NOT relevant in case > of LIR > allocations. > > When the policy was drafted, the concept of assignments/sub-assignments > did not > consider a practice very common in IPv4 which is replicated and even > amplified > in IPv6: the use of IP addresses for point-to-point links or VPNs. > > In IPv4, typically, this is not a problem if NAT is being used, because > the assigned > addresses are only for the WAN link, which is part of the infrastructure > or interconnection. > > In the case of IPv6, instead of unique addresses, the use of unique > prefixes > (/64) is increasingly common. > > Likewise, the policy failed to consider the use of IP addresses in > hotspots hotspots > (when is not an ISP, for example, associations or community networks), > or the use of > IP addresses by guests or employees in Bring Your Own Device (BYOD) and > many other > similar cases. > > One more case is when an end-user contracts a third-party to do some > services in their > own network and they need to deploy their own devices, even servers, > network equipment, > etc. For example, security surveillance services may require that the > contractor provides > their own cameras, recording system, even their own firewall and/or > router for a dedicated > VPN, etc. Of course, in many cases, this surveillance system may need to > use the addressing > space of the end-user. > > Finally, the IETF has recently approved the use of a unique /64 prefix > per interface/host > (RFC8273) instead of a unique address. This, for example, allows users > to connect to a hotspot, > receive a /64 such that they are “isolated” from other users (for > reasons of security, > regulatory requirements, etc.) and they can also use multiple virtual > machines on their > devices with a unique address for each one (within the same /64). > > > 2. Objective of policy change > - > > Section 2.2.3. (Definitions/Assigned Address Space), explicitly > prohibits such assignments, > stating that “Assigned ... may not be sub-assigned”. > > It also clarifies that the usage of sub-assignments in ISPs, data > centers and similar cases > is not allowed, according to the existing practices of APNIC. > > > 3. Situation in other regions > - > > This situation, has already been c
Re: [sig-policy] prop-124-v006: Clarification on Sub-Assignments
Hi Javed, I actually think this is in the other way around. I believe you’re confusing different terms, clearly described in the definitions section of the policy manual: 2.2.1. Delegated address space APNIC "delegates" addresses to its account holders. These delegations can be for use on the organization's own infrastructure (an "assignment") or for subsequent delegation by the organization to its customers (an "allocation"). 2.2.2. Allocated address space Allocated address space is address space that is distributed to IRs or other organizations for the purpose of subsequent distribution by them. 2.2.3. Assigned address space Assigned address space is address space that is delegated to an LIR, or end-user, for specific use within the Internet infrastructure they operate. Assignments must only be made for specific, documented purposes and may not be sub-assigned. This policy is only relevant to “assigments”. When an ISP (LIR) is getting addresses from APNIC for further distribution to customers, that space falls into the definition of “allocation”, so it is fine to further dirstribute it to other organizations. When an ISP (LIR) is getting “assigned” space from ACPNIC, is not for re-distribution. This is what I’m triyng to clarify. The fact that you are confused, I think, demonstrates that the actual text is subjected to multiple interpretations. As an ISP/LIR, which the current text, for different people reading it, a p2p link may be or not considered part of the infratructure. Perhaps you can say, it is ok to use for a p2p if the CPE is from the ISP, but otherwise not. My text clarify all the possible cases. Regards, Jordi @jordipalet El 29/8/19 2:49, "Javed Khan" escribió: Yes but the proposed text is not clear. In with the current policy text, LIRs are not allowed to make sub-assignments from their assigned address space outside of their infrastructure. So I do not support this change in policy. J Khan From: sig-policy-boun...@lists.apnic.net on behalf of Owen DeLong Sent: Saturday, 24 August 2019 12:45 AM To: Simon Sohel Baroi / Global Business / 01847102243 / Cc: Sumon Ahmed Sabir ; Policy SIG Subject: Re: [sig-policy] prop-124-v006: Clarification on Sub-Assignments I think the current text isn’t really a problem because reasonable people apply a reasonable interpretation of intent rather than the literal meaning. The proposal brings literal meaning more in line with well understood intent. While I don’t believe there is an actual problem to solve here, I do think the proposal provides greater clarity in the language and therefore support it. Owen On Aug 23, 2019, at 01:11, Simon Sohel Baroi / Global Business / 01847102243 / wrote: Dear Sir, Also, Requesting to the Author to represent the Proposal with Example and Graphical Representation. The example should have comparison with Present situation and the Propose Solution of the problem. - with regards SIMON. On Sat, Aug 10, 2019 at 8:33 PM Sumon Ahmed Sabir wrote: Dear SIG members A new version of the proposal "prop-124: Clarification on Sub-Assignments" has been sent to the Policy SIG for review. It will be presented at the Open Policy Meeting at APNIC 48 in Chiang Mai, Thailand on Thursday, 12 September 2019. Information about earlier versions is available from: https://www.apnic.net/community/policy/proposals/prop-124 You are encouraged to express your views on the proposal: - Do you support or oppose the proposal? - Is there anything in the proposal that is not clear? - What changes could be made to this proposal to make it more effective? Please find the text of the proposal below. Kind Regards, Sumon, Bertrand, Ching-Heng APNIC Policy SIG Chairs -- prop-124-v006: Clarification on Sub-Assignments -- Proposer: Jordi Palet Martínez jordi.pa...@theipv6company.com 1. Problem Statement Note that this proposal is ONLY relevant when end-users obtain direct assignments from APNIC, or when a LIR obtains, also from APNIC, and assignment for exclusive use within its infrastructure. Consequently this is NOT relevant in case of LIR allocations. When the policy was drafted, the concept of assignments/sub-assignments did not consider a practice very common in IPv4 which is replicated and even amplified in IPv6: the use of IP addresses for point-to-point links or VPNs. In IPv4, typically, this is not a problem if NAT is being used, because the assigned addresses are only for the WAN link, which is part of the infrastructure or interconnection. In the case of IPv6, instead of unique addresses, the use of unique prefixes (/64) is increasingly common. Likewise, t
Re: [sig-policy] prop-124-v006: Clarification on Sub-Assignments
n is good but no one is really concerned nor can verify this in practice. I think the current policy text is good. Kind regards Javed Khan MSCE and CCSP From: sig-policy-boun...@lists.apnic.net on behalf of Sumon Ahmed Sabir Sent: Saturday, 10 August 2019 10:33 PM To: Policy SIG Subject: [sig-policy] prop-124-v006: Clarification on Sub-Assignments Dear SIG members A new version of the proposal "prop-124: Clarification on Sub-Assignments" has been sent to the Policy SIG for review. It will be presented at the Open Policy Meeting at APNIC 48 in Chiang Mai, Thailand on Thursday, 12 September 2019. Information about earlier versions is available from: https://www.apnic.net/community/policy/proposals/prop-124 You are encouraged to express your views on the proposal: - Do you support or oppose the proposal? - Is there anything in the proposal that is not clear? - What changes could be made to this proposal to make it more effective? Please find the text of the proposal below. Kind Regards, Sumon, Bertrand, Ching-Heng APNIC Policy SIG Chairs -- prop-124-v006: Clarification on Sub-Assignments -- Proposer: Jordi Palet Martínez jordi.pa...@theipv6company.com 1. Problem Statement Note that this proposal is ONLY relevant when end-users obtain direct assignments from APNIC, or when a LIR obtains, also from APNIC, and assignment for exclusive use within its infrastructure. Consequently this is NOT relevant in case of LIR allocations. When the policy was drafted, the concept of assignments/sub-assignments did not consider a practice very common in IPv4 which is replicated and even amplified in IPv6: the use of IP addresses for point-to-point links or VPNs. In IPv4, typically, this is not a problem if NAT is being used, because the assigned addresses are only for the WAN link, which is part of the infrastructure or interconnection. In the case of IPv6, instead of unique addresses, the use of unique prefixes (/64) is increasingly common. Likewise, the policy failed to consider the use of IP addresses in hotspots hotspots (when is not an ISP, for example, associations or community networks), or the use of IP addresses by guests or employees in Bring Your Own Device (BYOD) and many other similar cases. One more case is when an end-user contracts a third-party to do some services in their own network and they need to deploy their own devices, even servers, network equipment, etc. For example, security surveillance services may require that the contractor provides their own cameras, recording system, even their own firewall and/or router for a dedicated VPN, etc. Of course, in many cases, this surveillance system may need to use the addressing space of the end-user. Finally, the IETF has recently approved the use of a unique /64 prefix per interface/host (RFC8273) instead of a unique address. This, for example, allows users to connect to a hotspot, receive a /64 such that they are “isolated” from other users (for reasons of security, regulatory requirements, etc.) and they can also use multiple virtual machines on their devices with a unique address for each one (within the same /64). 2. Objective of policy change - Section 2.2.3. (Definitions/Assigned Address Space), explicitly prohibits such assignments, stating that “Assigned ... may not be sub-assigned”. It also clarifies that the usage of sub-assignments in ISPs, data centers and similar cases is not allowed, according to the existing practices of APNIC. 3. Situation in other regions - This situation, has already been corrected in AFRINIC, ARIN, LACNIC and RIPE. 4. Proposed policy solution --- Current Text 2.2.3. Assigned address space Assigned address space is address space that is delegated to an LIR, or end-user, for specific use within the Internet infrastructure they operate. Assignments must only be made for specific, documented purposes and may not be sub-assigned. New text: 2.2.3. Assigned address space Assigned address space is address space that is delegated to an LIR, or end-user, for exclusive use within the infrastructure they operate, as well as for interconnection purposes. The assigned address space must only be used by the original recipient of the assignment, as well as for third party devices provided they are operating within said infrastructure. Therefore, sub-assignments to third parties outside said infrastructure (for example using sub-assignments for ISP customers), and providing addressing space to third parties in data-centers (or similar cases), are not allowed. 5. Advantages / Disadvantages - Advantages: Fulfilling the objective above indicated and making sure to ma
Re: [sig-policy] prop-124-v006: Clarification on Sub-Assignments
Dear Colleagues, I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team. I would like to share a feedback in our community for prop-124,based on a meeting we organized on 21th Aug to discuss these proposals. Many participants expressed a neutral for the proposal with reasons that the problem in the current policy is something vague. Best Regards, Satoru Tsurumaki JPOPF-ST 2019年8月10日(土) 23:33 Sumon Ahmed Sabir : > > Dear SIG members > > A new version of the proposal "prop-124: Clarification on Sub-Assignments" > has been sent to the Policy SIG for review. > > It will be presented at the Open Policy Meeting at APNIC 48 in > Chiang Mai, Thailand on Thursday, 12 September 2019. > > Information about earlier versions is available from: > https://www.apnic.net/community/policy/proposals/prop-124 > > You are encouraged to express your views on the proposal: > > - Do you support or oppose the proposal? > - Is there anything in the proposal that is not clear? > - What changes could be made to this proposal to make it more effective? > > Please find the text of the proposal below. > > Kind Regards, > > Sumon, Bertrand, Ching-Heng > APNIC Policy SIG Chairs > > > -- > > prop-124-v006: Clarification on Sub-Assignments > > -- > > Proposer: Jordi Palet Martínez >jordi.pa...@theipv6company.com > > > 1. Problem Statement > > > Note that this proposal is ONLY relevant when end-users obtain direct > assignments > from APNIC, or when a LIR obtains, also from APNIC, and assignment for > exclusive > use within its infrastructure. Consequently this is NOT relevant in case > of LIR > allocations. > > When the policy was drafted, the concept of assignments/sub-assignments > did not > consider a practice very common in IPv4 which is replicated and even > amplified > in IPv6: the use of IP addresses for point-to-point links or VPNs. > > In IPv4, typically, this is not a problem if NAT is being used, because > the assigned > addresses are only for the WAN link, which is part of the infrastructure > or interconnection. > > In the case of IPv6, instead of unique addresses, the use of unique > prefixes > (/64) is increasingly common. > > Likewise, the policy failed to consider the use of IP addresses in > hotspots hotspots > (when is not an ISP, for example, associations or community networks), > or the use of > IP addresses by guests or employees in Bring Your Own Device (BYOD) and > many other > similar cases. > > One more case is when an end-user contracts a third-party to do some > services in their > own network and they need to deploy their own devices, even servers, > network equipment, > etc. For example, security surveillance services may require that the > contractor provides > their own cameras, recording system, even their own firewall and/or > router for a dedicated > VPN, etc. Of course, in many cases, this surveillance system may need to > use the addressing > space of the end-user. > > Finally, the IETF has recently approved the use of a unique /64 prefix > per interface/host > (RFC8273) instead of a unique address. This, for example, allows users > to connect to a hotspot, > receive a /64 such that they are “isolated” from other users (for > reasons of security, > regulatory requirements, etc.) and they can also use multiple virtual > machines on their > devices with a unique address for each one (within the same /64). > > > 2. Objective of policy change > - > > Section 2.2.3. (Definitions/Assigned Address Space), explicitly > prohibits such assignments, > stating that “Assigned ... may not be sub-assigned”. > > It also clarifies that the usage of sub-assignments in ISPs, data > centers and similar cases > is not allowed, according to the existing practices of APNIC. > > > 3. Situation in other regions > - > > This situation, has already been corrected in AFRINIC, ARIN, LACNIC and > RIPE. > > > 4. Proposed policy solution > --- > > Current Text > 2.2.3. Assigned address space > Assigned address space is address space that is delegated to an LIR, or > end-user, > for specific use within the Internet infrastructure they operate. > Assignments must > only be made for specific, documented purposes and may not be sub-assigned. > > > New text: > 2.2.3. Assigned address space > Assigned address space is address space that is delegated to an LIR, or > end-user, > for exclusive use within the infrastructure they operate, as well as for > interconnection > purposes. > > The assigned address space must only be used by the original recipient > of the assignment, > as well as for third party devices provided they are operating within > said infrastructure. > > Therefore, sub-assignments to third parties outside said infrastructure > (for example > using sub-assignmen
Re: [sig-policy] prop-124-v006: Clarification on Sub-Assignments
From: sig-policy-boun...@lists.apnic.net on behalf of JORDI PALET MARTINEZ Sent: Monday, 26 August 2019 6:19 PM To: Policy SIG Subject: Re: [sig-policy] prop-124-v006: Clarification on Sub-Assignments Hi Javed, I think you’re getting something wrong. Policies aren’t there so APNIC can verify “everything” to “every” member. This will be impossible. Policies are there so everybody know the rules, and try their best to avoid breaking them. So is anyone breaking the current policy? can you provide examples? Policies are there to avoid bad-intentions from bad-Internet actors, in order to protect the majority (the good ones). If we only accept policies when they can be verified, then we will have an empty policy book :-) If APNIC does a verification, for whatever reason (any suspicius, a claim from another member, etc.), and a rule is broken, APNIC should take measures if the member doesn’t correct it. In some cases those measures may mean member closure, resource recovery, etc. This is a completely different discussion which has policy and service agreement implications. Please, note before continue reading that this only affects end-user direct assignments by APNIC or the NIRs. Not clarifiying this caused some confusion in the discussion of the last meeting. So if you’re an ISP (I’m not sure if that’s your case), this proposal doesn’t affect you. It only affect you, if you are getting a direct assignment from APNIC or any of the NIRs. I clearly understand that and I am not speaking for myself nor my organisation. The fact here is that if, for example, an university, which got a direct assignment from APNIC, is providing the students public addresses (IPv4) or global addresses (IPv6), it is against the policy. If the students are connecting to the university infrastructure to access resources, university is not breaking the current policy because the address space is still used for their infrastructure and not sub-assigned to students. In the case of IPv4, the solution is easy, use NAT and private addresses (but not all the universities do that). However in IPv6 this is not the solution, we don’t have NAT. Indeed everyone use NAT but the policies are not promoting to use NATs. Its a choice that the network providers make. I can put many other similar examples (remember again, this is only the case when the addresses are directly assigned to the end-user by APNIC or the NIR, not by an ISP): a point to point link from the university to another network, an employee getting addresses from a company, thir party companies offering services to that company or university, a municipality offering WiFi to citizens, etc. Employees getting addresses from a company is same as students in the university, as above. The proposal solves both cases, the IPv4 and the IPv6 one. Note that this has been already corrected in all the other RIRs (ARIN, AFRINIC, LACNIC and RIPE). All them had the same problem in their policy text. Ok but RIR regions are not all same and that's why we have an RIR for each region. If its corrected in one RIR doesn't mean that other RIR community has to follow that. Each RIR community can have its own discussion. Right? J Khan Regards, Jordi @jordipalet El 23/8/19 16:01, "Javed Khan" mailto:sig-policy-boun...@lists.apnic.net> en nombre de javedkha...@outlook.com<mailto:javedkha...@outlook.com>> escribió: I do not support this proposal. Intention is good but no one is really concerned nor can verify this in practice. I think the current policy text is good. Kind regards Javed Khan MSCE and CCSP From: sig-policy-boun...@lists.apnic.net on behalf of Sumon Ahmed Sabir Sent: Saturday, 10 August 2019 10:33 PM To: Policy SIG Subject: [sig-policy] prop-124-v006: Clarification on Sub-Assignments Dear SIG members A new version of the proposal "prop-124: Clarification on Sub-Assignments" has been sent to the Policy SIG for review. It will be presented at the Open Policy Meeting at APNIC 48 in Chiang Mai, Thailand on Thursday, 12 September 2019. Information about earlier versions is available from: https://www.apnic.net/community/policy/proposals/prop-124 You are encouraged to express your views on the proposal: - Do you support or oppose the proposal? - Is there anything in the proposal that is not clear? - What changes could be made to this proposal to make it more effective? Please find the text of the proposal below. Kind Regards, Sumon, Bertrand, Ching-Heng APNIC Policy SIG Chairs -- prop-124-v006: Clarification on Sub-Assignments -- Proposer: Jordi Palet Martínez jordi.pa...@theipv6company.com<mailto:jordi.pa.
Re: [sig-policy] prop-124-v006: Clarification on Sub-Assignments
Yes but the proposed text is not clear. In with the current policy text, LIRs are not allowed to make sub-assignments from their assigned address space outside of their infrastructure. So I do not support this change in policy. J Khan From: sig-policy-boun...@lists.apnic.net on behalf of Owen DeLong Sent: Saturday, 24 August 2019 12:45 AM To: Simon Sohel Baroi / Global Business / 01847102243 / Cc: Sumon Ahmed Sabir ; Policy SIG Subject: Re: [sig-policy] prop-124-v006: Clarification on Sub-Assignments I think the current text isn’t really a problem because reasonable people apply a reasonable interpretation of intent rather than the literal meaning. The proposal brings literal meaning more in line with well understood intent. While I don’t believe there is an actual problem to solve here, I do think the proposal provides greater clarity in the language and therefore support it. Owen On Aug 23, 2019, at 01:11, Simon Sohel Baroi / Global Business / 01847102243 / mailto:simon.ba...@fiberathome.net>> wrote: Dear Sir, Also, Requesting to the Author to represent the Proposal with Example and Graphical Representation. The example should have comparison with Present situation and the Propose Solution of the problem. - with regards SIMON. On Sat, Aug 10, 2019 at 8:33 PM Sumon Ahmed Sabir mailto:sasa...@gmail.com>> wrote: Dear SIG members A new version of the proposal "prop-124: Clarification on Sub-Assignments" has been sent to the Policy SIG for review. It will be presented at the Open Policy Meeting at APNIC 48 in Chiang Mai, Thailand on Thursday, 12 September 2019. Information about earlier versions is available from: https://www.apnic.net/community/policy/proposals/prop-124 You are encouraged to express your views on the proposal: - Do you support or oppose the proposal? - Is there anything in the proposal that is not clear? - What changes could be made to this proposal to make it more effective? Please find the text of the proposal below. Kind Regards, Sumon, Bertrand, Ching-Heng APNIC Policy SIG Chairs -- prop-124-v006: Clarification on Sub-Assignments -- Proposer: Jordi Palet Martínez jordi.pa...@theipv6company.com<mailto:jordi.pa...@theipv6company.com> 1. Problem Statement Note that this proposal is ONLY relevant when end-users obtain direct assignments from APNIC, or when a LIR obtains, also from APNIC, and assignment for exclusive use within its infrastructure. Consequently this is NOT relevant in case of LIR allocations. When the policy was drafted, the concept of assignments/sub-assignments did not consider a practice very common in IPv4 which is replicated and even amplified in IPv6: the use of IP addresses for point-to-point links or VPNs. In IPv4, typically, this is not a problem if NAT is being used, because the assigned addresses are only for the WAN link, which is part of the infrastructure or interconnection. In the case of IPv6, instead of unique addresses, the use of unique prefixes (/64) is increasingly common. Likewise, the policy failed to consider the use of IP addresses in hotspots hotspots (when is not an ISP, for example, associations or community networks), or the use of IP addresses by guests or employees in Bring Your Own Device (BYOD) and many other similar cases. One more case is when an end-user contracts a third-party to do some services in their own network and they need to deploy their own devices, even servers, network equipment, etc. For example, security surveillance services may require that the contractor provides their own cameras, recording system, even their own firewall and/or router for a dedicated VPN, etc. Of course, in many cases, this surveillance system may need to use the addressing space of the end-user. Finally, the IETF has recently approved the use of a unique /64 prefix per interface/host (RFC8273) instead of a unique address. This, for example, allows users to connect to a hotspot, receive a /64 such that they are “isolated” from other users (for reasons of security, regulatory requirements, etc.) and they can also use multiple virtual machines on their devices with a unique address for each one (within the same /64). 2. Objective of policy change - Section 2.2.3. (Definitions/Assigned Address Space), explicitly prohibits such assignments, stating that “Assigned ... may not be sub-assigned”. It also clarifies that the usage of sub-assignments in ISPs, data centers and similar cases is not allowed, according to the existing practices of APNIC. 3. Situation in other regions - This situation, has already been corrected in AFRINIC, ARIN, LACNIC and RIPE. 4. Proposed policy solution ---
Re: [sig-policy] prop-124-v006: Clarification on Sub-Assignments
> On Aug 26, 2019, at 03:19 , JORDI PALET MARTINEZ > wrote: > > Hi Javed, > > I think you’re getting something wrong. > > Policies aren’t there so APNIC can verify “everything” to “every” member. > This will be impossible. > > Policies are there so everybody know the rules, and try their best to avoid > breaking them. > > Policies are there to avoid bad-intentions from bad-Internet actors, in order > to protect the majority (the good ones). > > If we only accept policies when they can be verified, then we will have an > empty policy book :-) > > If APNIC does a verification, for whatever reason (any suspicius, a claim > from another member, etc.), and a rule is broken, APNIC should take measures > if the member doesn’t correct it. In some cases those measures may mean > member closure, resource recovery, etc. This is a completely different > discussion which has policy and service agreement implications. > > Please, note before continue reading that this only affects end-user direct > assignments by APNIC or the NIRs. Not clarifiying this caused some confusion > in the discussion of the last meeting. So if you’re an ISP (I’m not sure if > that’s your case), this proposal doesn’t affect you. > > It only affect you, if you are getting a direct assignment from APNIC or any > of the NIRs. > > The fact here is that if, for example, an university, which got a direct > assignment from APNIC, is providing the students public addresses (IPv4) or > global addresses (IPv6), it is against the policy. No, this does not violate current policy. The students are part of the University every bit as much as employees of a company are entitled to receive valid public addresses for their BYO smart phones/whatever in the office. That’s not sub assignment or reassignment, that’s just utilization within the Universities own network. > In the case of IPv4, the solution is easy, use NAT and private addresses (but > not all the universities do that). However in IPv6 this is not the solution, > we don’t have NAT. NAT is not required by current policy. The policy text as it stands does not prohibit the (temporary) use of public addresses on LAN or WLAN segments controlled by the entity holding the prefix even if the device(s) are not owned/directly controlled by the University. Especially in the case where the devices are in the possession/control of employees/students of the institution in question. If you think that is the case, then you have misunderstood the current policy. Owen > I can put many other similar examples (remember again, this is only the case > when the addresses are directly assigned to the end-user by APNIC or the NIR, > not by an ISP): a point to point link from the university to another network, > an employee getting addresses from a company, thir party companies offering > services to that company or university, a municipality offering WiFi to > citizens, etc. > > The proposal solves both cases, the IPv4 and the IPv6 one. > > Note that this has been already corrected in all the other RIRs (ARIN, > AFRINIC, LACNIC and RIPE). All them had the same problem in their policy text. > > Regards, > Jordi > > @jordipalet > > > > > > El 23/8/19 16:01, "Javed Khan" <mailto:sig-policy-boun...@lists.apnic.net> en nombre de > javedkha...@outlook.com <mailto:javedkha...@outlook.com>> escribió: > > I do not support this proposal. Intention is good but no one is really > concerned nor can verify this in practice. I think the current policy text is > good. > > Kind regards > Javed Khan > MSCE and CCSP > > From: sig-policy-boun...@lists.apnic.net > <mailto:sig-policy-boun...@lists.apnic.net> > <mailto:sig-policy-boun...@lists.apnic.net>> on behalf of Sumon Ahmed Sabir > mailto:sasa...@gmail.com>> > Sent: Saturday, 10 August 2019 10:33 PM > To: Policy SIG mailto:sig-pol...@apnic.net>> > Subject: [sig-policy] prop-124-v006: Clarification on Sub-Assignments > > Dear SIG members > > A new version of the proposal "prop-124: Clarification on Sub-Assignments" > has been sent to the Policy SIG for review. > > It will be presented at the Open Policy Meeting at APNIC 48 in > Chiang Mai, Thailand on Thursday, 12 September 2019. > > Information about earlier versions is available from: > https://www.apnic.net/community/policy/proposals/prop-124 > <https://www.apnic.net/community/policy/proposals/prop-124> > > You are encouraged to express your views on the proposal: > > - Do you support or oppose the proposal? > - Is there anything in the proposal t
Re: [sig-policy] prop-124-v006: Clarification on Sub-Assignments
Hi Javed, I think you’re getting something wrong. Policies aren’t there so APNIC can verify “everything” to “every” member. This will be impossible. Policies are there so everybody know the rules, and try their best to avoid breaking them. Policies are there to avoid bad-intentions from bad-Internet actors, in order to protect the majority (the good ones). If we only accept policies when they can be verified, then we will have an empty policy book :-) If APNIC does a verification, for whatever reason (any suspicius, a claim from another member, etc.), and a rule is broken, APNIC should take measures if the member doesn’t correct it. In some cases those measures may mean member closure, resource recovery, etc. This is a completely different discussion which has policy and service agreement implications. Please, note before continue reading that this only affects end-user direct assignments by APNIC or the NIRs. Not clarifiying this caused some confusion in the discussion of the last meeting. So if you’re an ISP (I’m not sure if that’s your case), this proposal doesn’t affect you. It only affect you, if you are getting a direct assignment from APNIC or any of the NIRs. The fact here is that if, for example, an university, which got a direct assignment from APNIC, is providing the students public addresses (IPv4) or global addresses (IPv6), it is against the policy. In the case of IPv4, the solution is easy, use NAT and private addresses (but not all the universities do that). However in IPv6 this is not the solution, we don’t have NAT. I can put many other similar examples (remember again, this is only the case when the addresses are directly assigned to the end-user by APNIC or the NIR, not by an ISP): a point to point link from the university to another network, an employee getting addresses from a company, thir party companies offering services to that company or university, a municipality offering WiFi to citizens, etc. The proposal solves both cases, the IPv4 and the IPv6 one. Note that this has been already corrected in all the other RIRs (ARIN, AFRINIC, LACNIC and RIPE). All them had the same problem in their policy text. Regards, Jordi @jordipalet El 23/8/19 16:01, "Javed Khan" escribió: I do not support this proposal. Intention is good but no one is really concerned nor can verify this in practice. I think the current policy text is good. Kind regards Javed Khan MSCE and CCSP From: sig-policy-boun...@lists.apnic.net on behalf of Sumon Ahmed Sabir Sent: Saturday, 10 August 2019 10:33 PM To: Policy SIG Subject: [sig-policy] prop-124-v006: Clarification on Sub-Assignments Dear SIG members A new version of the proposal "prop-124: Clarification on Sub-Assignments" has been sent to the Policy SIG for review. It will be presented at the Open Policy Meeting at APNIC 48 in Chiang Mai, Thailand on Thursday, 12 September 2019. Information about earlier versions is available from: https://www.apnic.net/community/policy/proposals/prop-124 You are encouraged to express your views on the proposal: - Do you support or oppose the proposal? - Is there anything in the proposal that is not clear? - What changes could be made to this proposal to make it more effective? Please find the text of the proposal below. Kind Regards, Sumon, Bertrand, Ching-Heng APNIC Policy SIG Chairs -- prop-124-v006: Clarification on Sub-Assignments -- Proposer: Jordi Palet Martínez jordi.pa...@theipv6company.com 1. Problem Statement Note that this proposal is ONLY relevant when end-users obtain direct assignments from APNIC, or when a LIR obtains, also from APNIC, and assignment for exclusive use within its infrastructure. Consequently this is NOT relevant in case of LIR allocations. When the policy was drafted, the concept of assignments/sub-assignments did not consider a practice very common in IPv4 which is replicated and even amplified in IPv6: the use of IP addresses for point-to-point links or VPNs. In IPv4, typically, this is not a problem if NAT is being used, because the assigned addresses are only for the WAN link, which is part of the infrastructure or interconnection. In the case of IPv6, instead of unique addresses, the use of unique prefixes (/64) is increasingly common. Likewise, the policy failed to consider the use of IP addresses in hotspots hotspots (when is not an ISP, for example, associations or community networks), or the use of IP addresses by guests or employees in Bring Your Own Device (BYOD) and many other similar cases. One more case is when an end-user contracts a third-party to do some services in their own network and they need to deploy their own devices, even servers, ne
Re: [sig-policy] prop-124-v006: Clarification on Sub-Assignments
I think the current text isn’t really a problem because reasonable people apply a reasonable interpretation of intent rather than the literal meaning. The proposal brings literal meaning more in line with well understood intent. While I don’t believe there is an actual problem to solve here, I do think the proposal provides greater clarity in the language and therefore support it. Owen > On Aug 23, 2019, at 01:11, Simon Sohel Baroi / Global Business / 01847102243 > / wrote: > > Dear Sir, > > Also, Requesting to the Author to represent the Proposal with Example and > Graphical Representation. > The example should have comparison with Present situation and the Propose > Solution of the problem. > > > - with regards > > SIMON. > >> On Sat, Aug 10, 2019 at 8:33 PM Sumon Ahmed Sabir wrote: >> Dear SIG members >> >> A new version of the proposal "prop-124: Clarification on Sub-Assignments" >> has been sent to the Policy SIG for review. >> >> It will be presented at the Open Policy Meeting at APNIC 48 in >> Chiang Mai, Thailand on Thursday, 12 September 2019. >> >> Information about earlier versions is available from: >> https://www.apnic.net/community/policy/proposals/prop-124 >> >> You are encouraged to express your views on the proposal: >> >> - Do you support or oppose the proposal? >> - Is there anything in the proposal that is not clear? >> - What changes could be made to this proposal to make it more effective? >> >> Please find the text of the proposal below. >> >> Kind Regards, >> >> Sumon, Bertrand, Ching-Heng >> APNIC Policy SIG Chairs >> >> >> -- >> >> prop-124-v006: Clarification on Sub-Assignments >> >> -- >> >> Proposer: Jordi Palet Martínez >>jordi.pa...@theipv6company.com >> >> >> 1. Problem Statement >> >> >> Note that this proposal is ONLY relevant when end-users obtain direct >> assignments >> from APNIC, or when a LIR obtains, also from APNIC, and assignment for >> exclusive >> use within its infrastructure. Consequently this is NOT relevant in case >> of LIR >> allocations. >> >> When the policy was drafted, the concept of assignments/sub-assignments >> did not >> consider a practice very common in IPv4 which is replicated and even >> amplified >> in IPv6: the use of IP addresses for point-to-point links or VPNs. >> >> In IPv4, typically, this is not a problem if NAT is being used, because >> the assigned >> addresses are only for the WAN link, which is part of the infrastructure >> or interconnection. >> >> In the case of IPv6, instead of unique addresses, the use of unique >> prefixes >> (/64) is increasingly common. >> >> Likewise, the policy failed to consider the use of IP addresses in >> hotspots hotspots >> (when is not an ISP, for example, associations or community networks), >> or the use of >> IP addresses by guests or employees in Bring Your Own Device (BYOD) and >> many other >> similar cases. >> >> One more case is when an end-user contracts a third-party to do some >> services in their >> own network and they need to deploy their own devices, even servers, >> network equipment, >> etc. For example, security surveillance services may require that the >> contractor provides >> their own cameras, recording system, even their own firewall and/or >> router for a dedicated >> VPN, etc. Of course, in many cases, this surveillance system may need to >> use the addressing >> space of the end-user. >> >> Finally, the IETF has recently approved the use of a unique /64 prefix >> per interface/host >> (RFC8273) instead of a unique address. This, for example, allows users >> to connect to a hotspot, >> receive a /64 such that they are “isolated” from other users (for >> reasons of security, >> regulatory requirements, etc.) and they can also use multiple virtual >> machines on their >> devices with a unique address for each one (within the same /64). >> >> >> 2. Objective of policy change >> - >> >> Section 2.2.3. (Definitions/Assigned Address Space), explicitly >> prohibits such assignments, >> stating that “Assigned ... may not be sub-assigned”. >> >> It also clarifies that the usage of sub-assignments in ISPs, data >> centers and similar cases >> is not allowed, according to the existing practices of APNIC. >> >> >> 3. Situation in other regions >> - >> >> This situation, has already been corrected in AFRINIC, ARIN, LACNIC and >> RIPE. >> >> >> 4. Proposed policy solution >> --- >> >> Current Text >> 2.2.3. Assigned address space >> Assigned address space is address space that is delegated to an LIR, or >> end-user, >> for specific use within the Internet infrastructure they operate. >> Assignments must >> only be made for specific, documented purposes and may n
Re: [sig-policy] prop-124-v006: Clarification on Sub-Assignments
Dear Sir, Also, Requesting to the Author to represent the Proposal with Example and Graphical Representation. The example should have comparison with Present situation and the Propose Solution of the problem. - with regards SIMON. On Sat, Aug 10, 2019 at 8:33 PM Sumon Ahmed Sabir wrote: > Dear SIG members > > A new version of the proposal "prop-124: Clarification on Sub-Assignments" > has been sent to the Policy SIG for review. > > It will be presented at the Open Policy Meeting at APNIC 48 in > Chiang Mai, Thailand on Thursday, 12 September 2019. > > Information about earlier versions is available from: > https://www.apnic.net/community/policy/proposals/prop-124 > > You are encouraged to express your views on the proposal: > > - Do you support or oppose the proposal? > - Is there anything in the proposal that is not clear? > - What changes could be made to this proposal to make it more effective? > > Please find the text of the proposal below. > > Kind Regards, > > Sumon, Bertrand, Ching-Heng > APNIC Policy SIG Chairs > > > -- > > prop-124-v006: Clarification on Sub-Assignments > > -- > > Proposer: Jordi Palet Martínez >jordi.pa...@theipv6company.com > > > 1. Problem Statement > > > Note that this proposal is ONLY relevant when end-users obtain direct > assignments > from APNIC, or when a LIR obtains, also from APNIC, and assignment for > exclusive > use within its infrastructure. Consequently this is NOT relevant in case > of LIR > allocations. > > When the policy was drafted, the concept of assignments/sub-assignments > did not > consider a practice very common in IPv4 which is replicated and even > amplified > in IPv6: the use of IP addresses for point-to-point links or VPNs. > > In IPv4, typically, this is not a problem if NAT is being used, because > the assigned > addresses are only for the WAN link, which is part of the infrastructure > or interconnection. > > In the case of IPv6, instead of unique addresses, the use of unique > prefixes > (/64) is increasingly common. > > Likewise, the policy failed to consider the use of IP addresses in > hotspots hotspots > (when is not an ISP, for example, associations or community networks), > or the use of > IP addresses by guests or employees in Bring Your Own Device (BYOD) and > many other > similar cases. > > One more case is when an end-user contracts a third-party to do some > services in their > own network and they need to deploy their own devices, even servers, > network equipment, > etc. For example, security surveillance services may require that the > contractor provides > their own cameras, recording system, even their own firewall and/or > router for a dedicated > VPN, etc. Of course, in many cases, this surveillance system may need to > use the addressing > space of the end-user. > > Finally, the IETF has recently approved the use of a unique /64 prefix > per interface/host > (RFC8273) instead of a unique address. This, for example, allows users > to connect to a hotspot, > receive a /64 such that they are “isolated” from other users (for > reasons of security, > regulatory requirements, etc.) and they can also use multiple virtual > machines on their > devices with a unique address for each one (within the same /64). > > > 2. Objective of policy change > - > > Section 2.2.3. (Definitions/Assigned Address Space), explicitly > prohibits such assignments, > stating that “Assigned ... may not be sub-assigned”. > > It also clarifies that the usage of sub-assignments in ISPs, data > centers and similar cases > is not allowed, according to the existing practices of APNIC. > > > 3. Situation in other regions > - > > This situation, has already been corrected in AFRINIC, ARIN, LACNIC and > RIPE. > > > 4. Proposed policy solution > --- > > Current Text > 2.2.3. Assigned address space > Assigned address space is address space that is delegated to an LIR, or > end-user, > for specific use within the Internet infrastructure they operate. > Assignments must > only be made for specific, documented purposes and may not be sub-assigned. > > > New text: > 2.2.3. Assigned address space > Assigned address space is address space that is delegated to an LIR, or > end-user, > for exclusive use within the infrastructure they operate, as well as for > interconnection > purposes. > > The assigned address space must only be used by the original recipient > of the assignment, > as well as for third party devices provided they are operating within > said infrastructure. > > Therefore, sub-assignments to third parties outside said infrastructure > (for example > using sub-assignments for ISP customers), and providing addressing space > to third > parties in data-centers (or similar cases), are not allowed. > > > 5. A
Re: [sig-policy] prop-124-v006: Clarification on Sub-Assignments
I do not support this proposal. Intention is good but no one is really concerned nor can verify this in practice. I think the current policy text is good. Kind regards Javed Khan MSCE and CCSP From: sig-policy-boun...@lists.apnic.net on behalf of Sumon Ahmed Sabir Sent: Saturday, 10 August 2019 10:33 PM To: Policy SIG Subject: [sig-policy] prop-124-v006: Clarification on Sub-Assignments Dear SIG members A new version of the proposal "prop-124: Clarification on Sub-Assignments" has been sent to the Policy SIG for review. It will be presented at the Open Policy Meeting at APNIC 48 in Chiang Mai, Thailand on Thursday, 12 September 2019. Information about earlier versions is available from: https://www.apnic.net/community/policy/proposals/prop-124 You are encouraged to express your views on the proposal: - Do you support or oppose the proposal? - Is there anything in the proposal that is not clear? - What changes could be made to this proposal to make it more effective? Please find the text of the proposal below. Kind Regards, Sumon, Bertrand, Ching-Heng APNIC Policy SIG Chairs -- prop-124-v006: Clarification on Sub-Assignments -- Proposer: Jordi Palet Martínez jordi.pa...@theipv6company.com<mailto:jordi.pa...@theipv6company.com> 1. Problem Statement Note that this proposal is ONLY relevant when end-users obtain direct assignments from APNIC, or when a LIR obtains, also from APNIC, and assignment for exclusive use within its infrastructure. Consequently this is NOT relevant in case of LIR allocations. When the policy was drafted, the concept of assignments/sub-assignments did not consider a practice very common in IPv4 which is replicated and even amplified in IPv6: the use of IP addresses for point-to-point links or VPNs. In IPv4, typically, this is not a problem if NAT is being used, because the assigned addresses are only for the WAN link, which is part of the infrastructure or interconnection. In the case of IPv6, instead of unique addresses, the use of unique prefixes (/64) is increasingly common. Likewise, the policy failed to consider the use of IP addresses in hotspots hotspots (when is not an ISP, for example, associations or community networks), or the use of IP addresses by guests or employees in Bring Your Own Device (BYOD) and many other similar cases. One more case is when an end-user contracts a third-party to do some services in their own network and they need to deploy their own devices, even servers, network equipment, etc. For example, security surveillance services may require that the contractor provides their own cameras, recording system, even their own firewall and/or router for a dedicated VPN, etc. Of course, in many cases, this surveillance system may need to use the addressing space of the end-user. Finally, the IETF has recently approved the use of a unique /64 prefix per interface/host (RFC8273) instead of a unique address. This, for example, allows users to connect to a hotspot, receive a /64 such that they are “isolated” from other users (for reasons of security, regulatory requirements, etc.) and they can also use multiple virtual machines on their devices with a unique address for each one (within the same /64). 2. Objective of policy change - Section 2.2.3. (Definitions/Assigned Address Space), explicitly prohibits such assignments, stating that “Assigned ... may not be sub-assigned”. It also clarifies that the usage of sub-assignments in ISPs, data centers and similar cases is not allowed, according to the existing practices of APNIC. 3. Situation in other regions - This situation, has already been corrected in AFRINIC, ARIN, LACNIC and RIPE. 4. Proposed policy solution --- Current Text 2.2.3. Assigned address space Assigned address space is address space that is delegated to an LIR, or end-user, for specific use within the Internet infrastructure they operate. Assignments must only be made for specific, documented purposes and may not be sub-assigned. New text: 2.2.3. Assigned address space Assigned address space is address space that is delegated to an LIR, or end-user, for exclusive use within the infrastructure they operate, as well as for interconnection purposes. The assigned address space must only be used by the original recipient of the assignment, as well as for third party devices provided they are operating within said infrastructure. Therefore, sub-assignments to third parties outside said infrastructure (for example using sub-assignments for ISP customers), and providing addressing space to third parties in data-centers (or similar cases), are not allowed. 5. Advantages / Disadvantages -
[sig-policy] prop-124-v006: Clarification on Sub-Assignments
Dear SIG members A new version of the proposal "prop-124: Clarification on Sub-Assignments" has been sent to the Policy SIG for review. It will be presented at the Open Policy Meeting at APNIC 48 in Chiang Mai, Thailand on Thursday, 12 September 2019. Information about earlier versions is available from: https://www.apnic.net/community/policy/proposals/prop-124 You are encouraged to express your views on the proposal: - Do you support or oppose the proposal? - Is there anything in the proposal that is not clear? - What changes could be made to this proposal to make it more effective? Please find the text of the proposal below. Kind Regards, Sumon, Bertrand, Ching-Heng APNIC Policy SIG Chairs -- prop-124-v006: Clarification on Sub-Assignments -- Proposer: Jordi Palet Martínez jordi.pa...@theipv6company.com 1. Problem Statement Note that this proposal is ONLY relevant when end-users obtain direct assignments from APNIC, or when a LIR obtains, also from APNIC, and assignment for exclusive use within its infrastructure. Consequently this is NOT relevant in case of LIR allocations. When the policy was drafted, the concept of assignments/sub-assignments did not consider a practice very common in IPv4 which is replicated and even amplified in IPv6: the use of IP addresses for point-to-point links or VPNs. In IPv4, typically, this is not a problem if NAT is being used, because the assigned addresses are only for the WAN link, which is part of the infrastructure or interconnection. In the case of IPv6, instead of unique addresses, the use of unique prefixes (/64) is increasingly common. Likewise, the policy failed to consider the use of IP addresses in hotspots hotspots (when is not an ISP, for example, associations or community networks), or the use of IP addresses by guests or employees in Bring Your Own Device (BYOD) and many other similar cases. One more case is when an end-user contracts a third-party to do some services in their own network and they need to deploy their own devices, even servers, network equipment, etc. For example, security surveillance services may require that the contractor provides their own cameras, recording system, even their own firewall and/or router for a dedicated VPN, etc. Of course, in many cases, this surveillance system may need to use the addressing space of the end-user. Finally, the IETF has recently approved the use of a unique /64 prefix per interface/host (RFC8273) instead of a unique address. This, for example, allows users to connect to a hotspot, receive a /64 such that they are “isolated” from other users (for reasons of security, regulatory requirements, etc.) and they can also use multiple virtual machines on their devices with a unique address for each one (within the same /64). 2. Objective of policy change - Section 2.2.3. (Definitions/Assigned Address Space), explicitly prohibits such assignments, stating that “Assigned ... may not be sub-assigned”. It also clarifies that the usage of sub-assignments in ISPs, data centers and similar cases is not allowed, according to the existing practices of APNIC. 3. Situation in other regions - This situation, has already been corrected in AFRINIC, ARIN, LACNIC and RIPE. 4. Proposed policy solution --- Current Text 2.2.3. Assigned address space Assigned address space is address space that is delegated to an LIR, or end-user, for specific use within the Internet infrastructure they operate. Assignments must only be made for specific, documented purposes and may not be sub-assigned. New text: 2.2.3. Assigned address space Assigned address space is address space that is delegated to an LIR, or end-user, for exclusive use within the infrastructure they operate, as well as for interconnection purposes. The assigned address space must only be used by the original recipient of the assignment, as well as for third party devices provided they are operating within said infrastructure. Therefore, sub-assignments to third parties outside said infrastructure (for example using sub-assignments for ISP customers), and providing addressing space to third parties in data-centers (or similar cases), are not allowed. 5. Advantages / Disadvantages - Advantages: Fulfilling the objective above indicated and making sure to match the real situation in the market. Disadvantages: None foreseen. 6. Impact on resource holders - None. 7. References - Links to RIPE policy amended and new policy proposal submitted. * sig-policy: APNIC SIG on resource management policy * ___ sig-policy mailing list sig-policy@lists.apnic.net http