This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
- Previous message (by thread): [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
- Next message (by thread): [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
JORDI PALET MARTINEZ
jordi.palet at consulintel.es
Mon Jan 15 14:21:39 CET 2018
Hi Marco, I feel then contradictory this: 2.6 change Providing another entity with separate addresses (not prefixes) from a subnet used on a link operated by the assignment holder is not considered a sub-assignment. This includes for example letting visitors connect to the assignment holder's network, connecting a server or appliance to an assignment holder's network and setting up point-¬to-point links with 3rd parties. Clearly say “not prefixes”. While, in the impact analysis: “If this proposal is accepted, it is the RIPE NCC’s understanding that for an IPv6 assignment, the provision of separate addresses to customers of the assignment holder will not be considered a sub-assignment. In IPv6 terms, a single address is a /128. There are cases where a /64 is needed per customer to provide a separate address, for instance by using dedicated (v)lans to connect Wifi customers or other configuration mechanisms discussed in the technical community. The RIPE NCC will consider such mechanisms as being in line with this policy and not a sub-assignment as long as the subnet size does not exceed a /64.” (by the way this mechanism is now RFC8273, so you could update the link to https://datatracker.ietf.org/doc/rfc8273/) I also don’t understand “either by varying the prefix or interface identifier (IID) over time”. While I agree on the first part, if you change the IID, you may be using it for privacy, but it may be also that the link is being used by a different hosts, or even mutiple hosts. This may mean a broadband customer with a /64 from an ISP that has only PI … I think this policy proposal is very harmful because it allows and even encourages, ISPs to just use PI and allocate customers with a single dynanic /128 or /64, which is terrible for IPv6 deployment. I believe this policy needs to: 1) Clearly allow /64 using RFC8273 2) Clearly disallow broadband services, unless is temporary “hotspots” connections (and similar cases, for example, BYOD in corporate networks, guest WiFi, etc.) 3) Clearly disallow a service of more than “few consecutive hours” (to avoid a company using PI to provide the service for employees or “guest” continuously) 4) I’m concerned also because I’m not sure if we want to allow using this policy for datacenters. Should datacenters be PA or PI? I tend to believe that they should be PA, may be NCC stats on this can help to clarify it. So, with the current text of this proposal I opposse to it, as it clearly has very important contradictions that need to be resolved before implementing it. Clearly I’m sure everybody will agree on working in improving it and resolving those, instead of requiring going to an appeal process. This is a suggestion for an alternative text: “Providing another entity with separate addresses (even /64 prefixes following RFC8273 or alternative technologies) from a subnet used on a link operated by the assignment holder is not considered a sub-assignment. This includes for example letting visitors and/or employees (BYOD) connect to the assignment holder's network, connecting a server or appliance to an assignment holder's network and setting up point-to-point links with 3rd parties. Provision of broadband services or connectivity to customers in a non-temporary way (“not a guest or employee for a few consecutive hours”) is considered a sub-assignment.” Thoughs? Regards, Jordi -----Mensaje original----- De: address-policy-wg <address-policy-wg-bounces at ripe.net> en nombre de Marco Schmidt <mschmidt at ripe.net> Fecha: lunes, 15 de enero de 2018, 12:53 Para: <address-policy-wg at ripe.net> Asunto: Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification) Dear Jordi, Thank you for your question. On 2018-01-15 11:21:10 CET, Jordi Palet Martinez wrote: > Furthermore, I will like a clarification from NCC about what I mention in the mike, I think is this comment: > > One of the opposing remark was that this would prevent "unique prefix > per host" style allocations, but that was addressed by Marco at the > APWG meeting already - the RS interpretation is "this would work". > My comment during the Address Policy WG session at RIPE 75 was referring to configuration mechanisms where a /64 is needed per customer to provide a separate address, for instance by using dedicated (V)LANs to connect WiFi customers. Such mechanisms will be considered in line with the policy. Section A of the impact analysis provides more details on our understanding for these cases. https://www.ripe.net/participate/policies/proposals/2016-04 I hope this clarifies. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum ********************************************** 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.
- Previous message (by thread): [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
- Next message (by thread): [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]