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
Wed Nov 8 12:29:50 CET 2017
Hi Elvis, I think the number of sub-assignments is something that can be very different in different cases and we may end-up with a new case that will not fit the policy. My rational to /64 is that actual IETF work direction is very consistent with a /64 to be used in a single interface (a host having VMs, for example) and I think this match very well what it may be the difference between PI and PA (while we keep it). https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-host/ Regards, Jordi -----Mensaje original----- De: address-policy-wg <address-policy-wg-bounces at ripe.net> en nombre de Elvis Daniel Velea <elvis at velea.eu> Responder a: <elvis at velea.eu> Fecha: miércoles, 8 de noviembre de 2017, 12:12 Para: <jordi.palet at consulintel.es> CC: <address-policy-wg at ripe.net> Asunto: Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification) Hi Jordi, Excuse the briefness of this mail, it was sent from a mobile device. > On Nov 8, 2017, at 02:20, JORDI PALET MARTINEZ <jordi.palet at consulintel.es> wrote: > > b. Arguments Opposing the Proposal > It can be argued that this proposal could increase the number of PI request to RIPE NCC. > > Mitigation/counter-argument: This is not an issue and should not be considered as a “bad-effect”. > > The resulting policy could be used to circumvent the allocation policy, avoiding creating a LIR. > > Mitigation/counter-argument: This seems not to have sense as there must be a justification process anyway, and because the starting point is /48, an ISP willing to connect customers, will really want to be an LIR. Furthermore, if we want to be restrictive on this, we could add a limitation that the maximum sub-assignment can be /64. how about... if we want to be restrictive - instead of limiting the size of the prefix, we limit the number of sub-assignments one can make from a PI? elvis ********************************************** 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 ]