From mschmidt at ripe.net Mon Jan 2 13:59:03 2017 From: mschmidt at ripe.net (Marco Schmidt) Date: Mon, 02 Jan 2017 13:59:03 +0100 Subject: [address-policy-wg] 2016-04 Review Phase: Draft Document and Impact Analysis Published (IPv6 PI Sub-assignment Clarification) Message-ID: Dear colleagues, The draft document for the proposal described in 2016-04, "IPv6 PI Sub-assignment Clarification" has been published. The impact analysis that was conducted for this proposal has also been published. The goal of this proposal is to define sub-assignments in IPv6 PI assignments as subnets of /64 and shorter. You can find the full proposal and the impact analysis at: https://www.ripe.net/participate/policies/proposals/2016-04 And the draft documents at: https://www.ripe.net/participate/policies/proposals/2016-04/draft We encourage you to review this proposal and send your comments to before 31 January 2017. Regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From Ondrej.Caletka at cesnet.cz Mon Jan 9 14:46:00 2017 From: Ondrej.Caletka at cesnet.cz (=?UTF-8?Q?Ond=c5=99ej_Caletka?=) Date: Mon, 9 Jan 2017 14:46:00 +0100 Subject: [address-policy-wg] 2016-04 Review Phase (IPv6 PI Sub-assignment Clarification) In-Reply-To: References: Message-ID: On 2.1.2017 v 13:59 Marco Schmidt wrote: > > We encourage you to review this proposal and send your comments to before 31 January 2017. Hi list, I would like to express my disagreement with the proposal. As I stated before [1], I think this proposal goes completely wrong way. After reading the impact analysis, I'm even more sure this is the case: To quote impact analysis: > Section 5.4.1 of the RIPE IPv6 policy mandates a /64 as the minimum assignment size per End Site within IPv6 allocations, while this policy change will make subnets smaller than a /64 per customer possible within IPv6 PI assignments. As I understand it, the proposer certainly don't want to lower the minimum of /64 per *End Site*. He just want to be able to operate a public Wi-Fi network within *his own End Site*. Another quote of impact analysis: > The current RIPE Database business rules prevent the creation of more specific objects under an object with the status ?ASSIGNED PI?, therefore these small subnets used by customers of the requesting organisation cannot be documented in the RIPE Database. This is starting to get ridiculous. Even if the database allowed creating sub-assignments under ASSIGNED PI, there is no technical way how to register every single device pulling address via SLAAC/DHCPv6 to the RIPE database, nor has been anything like that needed any time before. The RIPE Database is not a pan-European DHCP pool, is it? We really have to fix the RIPE NCC interpretations of "End Site" and "Assignment" so they don't consider a laptop connected to Wi-Fi network to be a separate End Site requiring it's own sub-assignment. This is the part that is broken and needs to be fixed, not the PI assignment rules. Best Regards, Ond?ej Caletka CESNET [1]: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2016-November/011943.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3718 bytes Desc: Elektronicky podpis S/MIME URL: From jordi.palet at consulintel.es Mon Jan 9 15:56:22 2017 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Mon, 09 Jan 2017 15:56:22 +0100 Subject: [address-policy-wg] 2016-04 Review Phase (IPv6 PI Sub-assignment Clarification) In-Reply-To: References: Message-ID: <760E3BC2-B60B-4627-B27C-9E5CBC74A5F2@consulintel.es> Fully agree. I?ve also expressed my concern about this being the wrong way. I?ve also discussed in private with the author regarding several issues, including how wrong is having a text that mention something like /80. From RFC7136: For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long. If derived from an IEEE MAC-layer address, they must be constructed in Modified EUI-64 format. The impact analysis mention /64 as the minimum, but is not the minimum, is the ONLY valid value. There is only an exception to that: point-to-point links. Now, what happens if the assignment is not /64, but several /64 for each ?machine?, as being suggested by new IETF work? For example, the servers and employee computers in a company that has received a /48 IPv6 PI, will be in this case. They may decide to allocate a single /64 for each VLAN (computers may be from the company or from employees, such as cellular phones, tablets, laptops), but maybe they prefer to allocate a /64 for each computer ? and may be in the future several /64 for each computer, because they are running virtual machines in different VLANs. I suggested several options, for example trying to adjust the definition of ?infrastructure?, ?assign?, or even other choices such as: The PI assignment cannot be further assigned to other organisations. An exception to this will be managed services to third parties or point to point links, using the PI owner, own managed infrastructure; in that case, will not be subjected to registration, and it will not be considered as a sub-assignment, regardless size of the addressing space being used for those services (from a single address to multiple /64). An example of this will be a company offering managed networking services to SMEs to connect user-devices or even servers, such as: Users in public hot spots, employees or guest SSIDs or VPNs or VLANs or LAN segments in organizations, servers in a data centre. or Within the context of this policy, assignments not done to end-sites by means of point-to-point links are not considered sub-assignments. I know is not neither of those are perfect, and may not work, but it may be a starting point for some more discussion. And last idea (shooting to my own foot, as original author of the IPv6 PI policy proposal) ? Do we really need anymore a different rule for IPv6 PA and IPv6 PI ???? Regards, Jordi -----Mensaje original----- De: address-policy-wg en nombre de Ond?ej Caletka Responder a: Fecha: lunes, 9 de enero de 2017, 14:46 Para: Asunto: Re: [address-policy-wg] 2016-04 Review Phase (IPv6 PI Sub-assignment Clarification) On 2.1.2017 v 13:59 Marco Schmidt wrote: > > We encourage you to review this proposal and send your comments to before 31 January 2017. Hi list, I would like to express my disagreement with the proposal. As I stated before [1], I think this proposal goes completely wrong way. After reading the impact analysis, I'm even more sure this is the case: To quote impact analysis: > Section 5.4.1 of the RIPE IPv6 policy mandates a /64 as the minimum assignment size per End Site within IPv6 allocations, while this policy change will make subnets smaller than a /64 per customer possible within IPv6 PI assignments. As I understand it, the proposer certainly don't want to lower the minimum of /64 per *End Site*. He just want to be able to operate a public Wi-Fi network within *his own End Site*. Another quote of impact analysis: > The current RIPE Database business rules prevent the creation of more specific objects under an object with the status ?ASSIGNED PI?, therefore these small subnets used by customers of the requesting organisation cannot be documented in the RIPE Database. This is starting to get ridiculous. Even if the database allowed creating sub-assignments under ASSIGNED PI, there is no technical way how to register every single device pulling address via SLAAC/DHCPv6 to the RIPE database, nor has been anything like that needed any time before. The RIPE Database is not a pan-European DHCP pool, is it? We really have to fix the RIPE NCC interpretations of "End Site" and "Assignment" so they don't consider a laptop connected to Wi-Fi network to be a separate End Site requiring it's own sub-assignment. This is the part that is broken and needs to be fixed, not the PI assignment rules. Best Regards, Ond?ej Caletka CESNET [1]: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2016-November/011943.html ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From raymond.jetten at elisa.fi Mon Jan 9 15:19:03 2017 From: raymond.jetten at elisa.fi (Jetten Raymond) Date: Mon, 9 Jan 2017 14:19:03 +0000 Subject: [address-policy-wg] 2016-04 Review Phase (IPv6 PI Sub-assignment Clarification) In-Reply-To: References: Message-ID: <29b63c9e97804db4877513d1717aa972@elisa.fi> Hi list & Ond?ej, I Share this feeling. An end user to me is a user that permanently with or without a contract uses a certain (call it assigned or agreed) or logical block of addresses. The wifi will probably not give out permanent addresses that can be claimed back the next time, so I see no point in the sub allocation either. Rgds, Ray -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Ondrej Caletka Sent: 9. tammikuuta 2017 15:46 To: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2016-04 Review Phase (IPv6 PI Sub-assignment Clarification) On 2.1.2017 v 13:59 Marco Schmidt wrote: > > We encourage you to review this proposal and send your comments to before 31 January 2017. Hi list, I would like to express my disagreement with the proposal. As I stated before [1], I think this proposal goes completely wrong way. After reading the impact analysis, I'm even more sure this is the case: To quote impact analysis: > Section 5.4.1 of the RIPE IPv6 policy mandates a /64 as the minimum assignment size per End Site within IPv6 allocations, while this policy change will make subnets smaller than a /64 per customer possible within IPv6 PI assignments. As I understand it, the proposer certainly don't want to lower the minimum of /64 per *End Site*. He just want to be able to operate a public Wi-Fi network within *his own End Site*. Another quote of impact analysis: > The current RIPE Database business rules prevent the creation of more specific objects under an object with the status ?ASSIGNED PI?, therefore these small subnets used by customers of the requesting organisation cannot be documented in the RIPE Database. This is starting to get ridiculous. Even if the database allowed creating sub-assignments under ASSIGNED PI, there is no technical way how to register every single device pulling address via SLAAC/DHCPv6 to the RIPE database, nor has been anything like that needed any time before. The RIPE Database is not a pan-European DHCP pool, is it? We really have to fix the RIPE NCC interpretations of "End Site" and "Assignment" so they don't consider a laptop connected to Wi-Fi network to be a separate End Site requiring it's own sub-assignment. This is the part that is broken and needs to be fixed, not the PI assignment rules. Best Regards, Ond?ej Caletka CESNET [1]: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2016-November/011943.html From max at rfc2324.org Tue Jan 10 18:58:24 2017 From: max at rfc2324.org (Maximilian Wilhelm) Date: Tue, 10 Jan 2017 18:58:24 +0100 Subject: [address-policy-wg] 2016-04 Review Phase (IPv6 PI Sub-assignment Clarification) In-Reply-To: <760E3BC2-B60B-4627-B27C-9E5CBC74A5F2@consulintel.es> References: <760E3BC2-B60B-4627-B27C-9E5CBC74A5F2@consulintel.es> Message-ID: <20170110175824.GP1074@principal.rfc2324.org> Anno domini 2017 JORDI PALET MARTINEZ scripsit: > Fully agree. I?ve also expressed my concern about this being the wrong way. > I?ve also discussed in private with the author regarding several issues, including how wrong is having a text that mention something like /80. From RFC7136: [...] So, for shooting myself into my own foot (to steal your wording): I'm inclined to agree with you. After reading the IA I'm unsure wether the prefix length approach is leading to the best solution of this problem. I thought on this a while and basicly came up with similar ideas to yours but had a hard time putting it into words. So whatever journey this proposal will have from here on, at least we got into a discussion about an issue we at least can agree on exists. :) > Now, what happens if the assignment is not /64, but several /64 for each ?machine?, as being suggested by new IETF work? > > For example, the servers and employee computers in a company that has received a /48 IPv6 PI, will be in this case. They may decide to allocate a single /64 for each VLAN (computers may be from the company or from employees, such as cellular phones, tablets, laptops), but maybe they prefer to allocate a /64 for each computer ? and may be in the future several /64 for each computer, because they are running virtual machines in different VLANs. > > I suggested several options, for example trying to adjust the definition of ?infrastructure?, ?assign?, or even other choices such as: > > The PI assignment cannot be further assigned to other organisations. An exception to this will be managed services to third parties or point to point links, using the PI owner, own managed infrastructure; in that case, will not be subjected to registration, and it will not be considered as a sub-assignment, regardless size of the addressing space being used for those services (from a single address to multiple /64). An example of this will be a company offering managed networking services to SMEs to connect user-devices or even servers, such as: Users in public hot spots, employees or guest SSIDs or VPNs or VLANs or LAN segments in organizations, servers in a data centre. (SMEs are Small and medium-sized enterprises?) That would be something I'd be rather fine with. It solves the problems people faced in a more general way. I opens up some use cases and scenarios - which I tried to avoid to keep the scope of this discussion limited - but might be a nifty solution to clear these problems once and for all. This will however touch the PI/PA question as it opens up the usage of PI space for hosting providers and the like which I was trying to avoid, too. > or > > Within the context of this policy, assignments not done to end-sites by means of point-to-point links are not considered sub-assignments. That would be bit to vague for my taste. > I know is not neither of those are perfect, and may not work, but it may be a starting point for some more discussion. > And last idea (shooting to my own foot, as original author of the IPv6 PI policy proposal) ? Do we really need anymore a different rule for IPv6 PA and IPv6 PI ???? That in particular was a subject I tried to avoid touching ;-) Best Max -- "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mahatma Gandhi From mschmidt at ripe.net Tue Jan 24 14:13:43 2017 From: mschmidt at ripe.net (Marco Schmidt) Date: Tue, 24 Jan 2017 14:13:43 +0100 Subject: [address-policy-wg] 2016-05 New Version and Impact Analysis Published (Synchronising the Initial and Subsequent IPv6 Allocation Policies) Message-ID: Dear colleagues, The draft documents for version 2.0 of the policy proposal 2016-05, "Synchronising the Initial and Subsequent IPv6 Allocation Policies" has now been published, along with an impact analysis conducted by the RIPE NCC. The goal of this proposal is to match the subsequent IPv6 allocation requirements with the initial allocation requirements. Some of the differences from version 1.0 include: - Revert initial changes to the HD-ratio calculation - Clarification as to when the new need justifies a subsequent allocation - Clarification as to what the subsequent allocation size will be based on You can find the full proposal and the impact analysis at: https://www.ripe.net/participate/policies/proposals/2016-05 And the draft documents at: https://www.ripe.net/participate/policies/proposals/2016-05/draft We encourage you to read the draft document and send any comments to before 22 February 2017. Regards Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From herve.clement at orange.com Fri Jan 27 17:00:58 2017 From: herve.clement at orange.com (herve.clement at orange.com) Date: Fri, 27 Jan 2017 16:00:58 +0000 Subject: [address-policy-wg] 2016-04 Review Phase: Draft Document and Impact Analysis Published (IPv6 PI Sub-assignment Clarification) In-Reply-To: References: Message-ID: <9466_1485532859_588B6EBB_9466_6295_1_2AF4C0655C93DD4D9A005252D465A8083EB1C30E@OPEXCLILM21.corporate.adroot.infra.ftgroup> Hi, I'm in favour of this policy proposal, even if the impacts related to the global v6 routing table should be studied more carefully. Herv? CLEMENT -----Message d'origine----- De : address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] De la part de Marco Schmidt Envoy? : lundi 2 janvier 2017 13:59 ? : address-policy-wg at ripe.net Objet : [address-policy-wg] 2016-04 Review Phase: Draft Document and Impact Analysis Published (IPv6 PI Sub-assignment Clarification) Dear colleagues, The draft document for the proposal described in 2016-04, "IPv6 PI Sub-assignment Clarification" has been published. The impact analysis that was conducted for this proposal has also been published. The goal of this proposal is to define sub-assignments in IPv6 PI assignments as subnets of /64 and shorter. You can find the full proposal and the impact analysis at: https://www.ripe.net/participate/policies/proposals/2016-04 And the draft documents at: https://www.ripe.net/participate/policies/proposals/2016-04/draft We encourage you to review this proposal and send your comments to > before 31 January 2017. Regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: