En la política de IPv4, a la hora de asignaciones directas de LACNIC a usuarios finales, se habla de subdelegación (2.3.3.4.), y explícitamente se prohíbe a terceras partes.
En la política de IPv6 no hay un texto explícito que lo prohíba, salvo en el caso de las microasignaciones (no se podrán realizar sub-asignaciones, 4.5.5.).
Sin embargo, en las definiciones, el punto 1.9 "Asignar", que afecta a todas las políticas de LACNIC, explícitamente las prohíbe "y no para ser subasignadas a otras partes".
Esta propuesta busca clarificar el texto de la política IPv6 al respecto, y definir mejor el concepto, especialmente teniendo en cuenta nuevos usos de IPv6 (RFC8273).
Rationale (Describe the problem you intend to solve)Cuando se diseñó, en la política, el concepto de asignar/subasignar, no se tuvo en cuenta una práctica muy común en IPv4, que se reproduce e incluso magnifica en IPv6: El uso de direcciones para los enlaces punto-a-punto o VPNs.
En el caso de IPv6, en lugar de direcciones únicas, es más habitual el uso de prefijos (/64).
Además, tampoco se tuvo en cuenta el uso de direcciones en hot-spots, o el uso de direcciones por parte de invitados o empleados de una entidad (BYOD "Bring Your Own Device"), y muchos otros casos similares.
Finalmente, el IETF ha aprobado recientemente un concepto de uso de prefijos /64 en interfaces/hosts (RFC8273), en lugar de direcciones únicas, que permite por ejemplo que un usuario se conecte a un hot-spot, reciba un /64, de forma que esta "aislado" (por seguridad, necesidades de legislación, etc.), de otros usuarios y además puede usar máquinas virtuales dentro de su dispositivo con direcciones únicas para cada una de ellas (dentro del mismo /64).
Current textTexto actual:
No existe.
Nuevo texto:
Nuevo párrafo tras el párrafo existente en 4.5.4. (Asignaciones directas a Usuarios Finales)
Mismo párrafo tras el último párrafo en 4.5.5. (Microasignación en IPv6)
No se considerará sub-asignación cuando se proporcione a terceras partes una dirección o incluso un único prefijo /64 (ejemplo, RFC8273), de forma temporal, en un enlace operado por el receptor original de la asignación. Esto incluye, por ejemplo, invitados o empleados (BYOD, dispositivos o servidores), hot-spots y enlaces punto-a-punto o VPNs. Proporcionar servicios de banda-ancha o conectividad de forma no-temporal, sigue siendo una sub-asignación y, por tanto, no está permitido.
New textTexto actual:
No existe.
Nuevo texto:
Nuevo párrafo tras el párrafo existente en 4.5.4. (Asignaciones directas a Usuarios Finales)
Mismo párrafo tras el último párrafo en 4.5.5. (Microasignación en IPv6)
No se considerará sub-asignación cuando se proporcione a terceras partes una dirección o incluso un único prefijo /64 (ejemplo, RFC8273), de forma temporal, en un enlace operado por el receptor original de la asignación. Esto incluye, por ejemplo, invitados o empleados (BYOD, dispositivos o servidores), hot-spots y enlaces punto-a-punto o VPNs. Proporcionar servicios de banda-ancha o conectividad de forma no-temporal, sigue siendo una sub-asignación y, por tanto, no está permitido.
Additional information-
TimetableInmediato
ReferencesRIPE ha debatido una propuesta similar y se está a la espera de la declaración de consenso por parte de los chairs.
Presented at:-
En la política de IPv4, a la hora de asignaciones directas de LACNIC a usuarios finales, se habla de subdelegación (2.3.3.4.), y explícitamente se prohíbe a terceras partes.
En la política de IPv6 no hay un texto explícito que lo prohíba, salvo en el caso de las microasignaciones (no se podrán realizar sub-asignaciones, 4.5.5.).
Sin embargo, en las definiciones, el punto 1.9 "Asignar", que afecta a todas las políticas de LACNIC, explícitamente las prohíbe "y no para ser subasignadas a otras partes".
Esta propuesta busca clarificar el texto de la política IPv6 al respecto, y definir mejor el concepto, especialmente teniendo en cuenta nuevos usos de IPv6 (RFC8273).
Rationale (Describe the problem you intend to solve)Cuando se diseñó, en la política, el concepto de asignar/subasignar, no se tuvo en cuenta una práctica muy común en IPv4, que se reproduce e incluso magnifica en IPv6: El uso de direcciones para los enlaces punto-a-punto o VPNs.
En el caso de IPv6, en lugar de direcciones únicas, es más habitual el uso de prefijos (/64).
Además, tampoco se tuvo en cuenta el uso de direcciones en hot-spots, o el uso de direcciones por parte de invitados o empleados de una entidad (BYOD "Bring Your Own Device"), y muchos otros casos similares.
Finalmente, el IETF ha aprobado recientemente un concepto de uso de prefijos /64 en interfaces/hosts (RFC8273), en lugar de direcciones únicas, que permite por ejemplo que un usuario se conecte a un hot-spot, reciba un /64, de forma que esta "aislado" (por seguridad, necesidades de legislación, etc.), de otros usuarios y además puede usar máquinas virtuales dentro de su dispositivo con direcciones únicas para cada una de ellas (dentro del mismo /64).
Current textTexto actual:
No existe.
Nuevo texto:
Nuevo párrafo tras el párrafo existente en 4.5.4. (Asignaciones directas a Usuarios Finales)
Mismo párrafo tras el último párrafo en 4.5.5. (Microasignación en IPv6)
No se considerará sub-asignación cuando se proporcione a terceras partes una dirección o incluso un único prefijo /64, de forma no-permanente, en un enlace operado por el receptor original de la asignación. Esto incluye, por ejemplo, invitados o empleados (dispositivos o servidores), hot-spots y enlaces punto-a-punto o VPNs.
Proporcionar servicios de banda-ancha o conectividad de forma permanente, sigue siendo una sub-asignación y, por tanto, no está permitido. Sólo el direccionamiento del propio enlace punto-a-punto puede ser permanente y dicho direccionamiento no puede ser usado (ni directa ni indirectamente) para la propia comunicación.
New textTexto actual:
No existe.
Nuevo texto:
Nuevo párrafo tras el párrafo existente en 4.5.4. (Asignaciones directas a Usuarios Finales)
Mismo párrafo tras el último párrafo en 4.5.5. (Microasignación en IPv6)
No se considerará sub-asignación cuando se proporcione a terceras partes una dirección o incluso un único prefijo /64, de forma no-permanente, en un enlace operado por el receptor original de la asignación. Esto incluye, por ejemplo, invitados o empleados (dispositivos o servidores), hot-spots y enlaces punto-a-punto o VPNs.
Proporcionar servicios de banda-ancha o conectividad de forma permanente, sigue siendo una sub-asignación y, por tanto, no está permitido. Sólo el direccionamiento del propio enlace punto-a-punto puede ser permanente y dicho direccionamiento no puede ser usado (ni directa ni indirectamente) para la propia comunicación.
Additional information-
TimetableInmediato
ReferencesRIPE ha debatido una propuesta similar y se está a la espera de la declaración de consenso por parte de los chairs.
Presented at:LACNIC 29 (30/04/2018)
En la política de IPv4, a la hora de asignaciones directas de LACNIC a usuarios finales, se habla de subdelegación (2.3.3.4.), y explícitamente se prohíbe a terceras partes.
En la política de IPv6 no hay un texto explícito que lo prohíba, salvo en el caso de las microasignaciones (no se podrán realizar sub-asignaciones, 4.5.5.).
Sin embargo, en las definiciones, el punto 1.9 “Asignar”, que afecta a todas las políticas de LACNIC, explícitamente las prohíbe “y no para ser subasignadas a otras partes”.
Esta propuesta busca clarificar el texto de la política IPv6 al respecto, y definir mejor el concepto, especialmente teniendo en cuenta nuevos usos de IPv6 (RFC8273).
Rationale (Describe the problem you intend to solve)Cuando se diseñó, en la política, el concepto de asignar/subasignar, no se tuvo en cuenta una práctica muy común en IPv4, que se reproduce e incluso magnifica en IPv6: El uso de direcciones para los enlaces punto-a-punto o VPNs.
En el caso de IPv6, en lugar de direcciones únicas, es más habitual el uso de prefijos (/64).
Además, tampoco se tuvo en cuenta el uso de direcciones en hot-spots, o el uso de direcciones por parte de invitados o empleados de una entidad (BYOD “Bring Your Own Device”), y muchos otros casos similares.
Otro caso que también se ve impacto, se produce cuando un usuario final contrata a otra compañía para que le proporcione algunos servicios y para ello se requiere desplegar sus propios dispositivos, incluso servidores, equipamiento de red, etc. Por ejemplo, un servicio de vigilancia de seguridad, podría requerir que el contratista proporcione sus propias cámaras, sistema de grabación, e incluso su propio cortafuegos y/o un router para una VPN dedicada, etc. Por supuesto, en muchos casos, este sistema de videovigilancia podría requerir utilizar espacio de direcciones del usuario final.
Finalmente, el IETF ha aprobado recientemente un concepto de uso de prefijos /64 en interfaces/hosts (RFC8273), en lugar de direcciones únicas, que permite por ejemplo que un usuario se conecte a un hot-spot, reciba un /64, de forma que esta “aislado” (por seguridad, necesidades de legislación, etc.), de otros usuarios y además puede usar máquinas virtuales dentro de su dispositivo con direcciones únicas para cada una de ellas (dentro del mismo /64).
Current textTexto actual:
No existe.
Nuevo texto:
Nuevo párrafo tras el párrafo existente en 4.5.4. (Asignaciones directas a Usuarios Finales)
Mismo párrafo tras el último párrafo en 4.5.5. (Microasignación en IPv6)
Proporcionar espacio de direcciones a dispositivos de terceros, incluyendo direcciones para enlaces punto-a-punto y/o proporcionar de forma no-permanente espacio de direcciones a terceras partes, para su uso en una red gestionada y operada por el receptor original de la asignación, no se considerará sub-asignación.
Proporcionar espacio de direcciones para servicios de conectividad (semi-)permanente, como servicios de banda-ancha, sigue siendo una sub-asignación.
New textTexto actual:
No existe.
Nuevo texto:
Nuevo párrafo tras el párrafo existente en 4.5.4. (Asignaciones directas a Usuarios Finales)
Mismo párrafo tras el último párrafo en 4.5.5. (Microasignación en IPv6)
Proporcionar espacio de direcciones a dispositivos de terceros, incluyendo direcciones para enlaces punto-a-punto y/o proporcionar de forma no-permanente espacio de direcciones a terceras partes, para su uso en una red gestionada y operada por el receptor original de la asignación, no se considerará sub-asignación.
Proporcionar espacio de direcciones para servicios de conectividad (semi-)permanente, como servicios de banda-ancha, sigue siendo una sub-asignación.
Additional information-
TimetableInmediato
ReferencesRIPE ha debatido una propuesta similar y se está a la espera de la declaración de consenso por parte de los chairs.
Presented at:LACNIC 30 (24/09/2018)
En la política de IPv4, a la hora de asignaciones directas de LACNIC a usuarios finales, se habla de subdelegación (2.3.3.4.), y explícitamente se prohíbe a terceras partes.
En la política de IPv6 no hay un texto explícito que lo prohíba, salvo en el caso de las micro-asignaciones (no se podrán realizar sub-asignaciones, 4.5.5.).
Sin embargo, en las definiciones, el punto 1.9 “Asignar”, que afecta a todas las políticas de LACNIC, explícitamente las prohíbe “y no para ser sub-asignadas a otras partes”.
Esta propuesta busca clarificar el texto de la política IPv6 al respecto, y definir mejor el concepto, especialmente teniendo en cuenta nuevos usos de IPv6 (RFC8273).
Por último, en la lengua Española, no existen palabras como subasignación, microasignación, subasignadas, subasignar, sino que lo correcto es usar un guion medio “-“ para separar el prefijo de la palabra y se propone el cambio en todo el manual de políticas de todas las palabras que contengan los prefijos “micro”, “macro”, “sub” y similares.
Rationale (Describe the problem you intend to solve)Cuando se diseñó, en la política, el concepto de asignar/sub-asignar, no se tuvo en cuenta una práctica muy común en IPv4, que se reproduce e incluso magnifica en IPv6: El uso de direcciones para los enlaces punto-a-punto o VPNs.
En el caso de IPv4, habitualmente se utiliza NAT y por tanto no hay implicaciones. Sin embargo, en aquellos casos de instituciones que no usan NAT, el problema es el mismo que para IPv6.
En el caso de IPv6, en lugar de direcciones únicas, es más habitual el uso de prefijos (/64).
Además, tampoco se tuvo en cuenta el uso de direcciones en hot-spots, o el uso de direcciones por parte de invitados o empleados de una entidad (BYOD “Bring Your Own Device”), y muchos otros casos similares.
Otro caso que también se ve impacto, se produce cuando un usuario final contrata a otra compañía para que le proporcione algunos servicios y para ello se requiere desplegar sus propios dispositivos, incluso servidores, equipamiento de red, etc. Por ejemplo, un servicio de vigilancia de seguridad, podría requerir que el contratista proporcione sus propias cámaras, sistema de grabación, e incluso su propio cortafuegos y/o un router para una VPN dedicada, etc. Por supuesto, en muchos casos, este sistema de video-vigilancia podría requerir utilizar espacio de direcciones del usuario final.
Finalmente, el IETF ha aprobado recientemente un concepto de uso de prefijos /64 en interfaces/hosts (RFC8273), en lugar de direcciones únicas, que permite por ejemplo que un usuario se conecte a un hot-spot, reciba un /64, de forma que esta “aislado” (por seguridad, necesidades de legislación, etc.), de otros usuarios y además puede usar máquinas virtuales dentro de su dispositivo con direcciones únicas para cada una de ellas (dentro del mismo /64).
En algunas partes del manual se utiliza el guion medio (“-“), que es lo correcto, para separar prefijos “sub”, “micro” y similares, y en otras no. Se trata de uniformizarlo.
Current textTexto actual:
1.9 Asignar
Asignar significa delegar espacio de direcciones a un usuario final, para su uso específico dentro de la infraestructura de Internet que ellos operan. La asignación de espacio de direcciones debe ser realizada solamente para los propósitos específicos documentados por organizaciones específicas y no para ser subasignadas a otras partes.
Nuevo texto:
1.9 Asignar
Asignar significa delegar espacio de direcciones a un usuario final, para su uso específico dentro de la infraestructura de Internet que ellos operan.
Los enlaces punto-a-punto, VPNs y similares, se consideran como parte de dicha infraestructura y por tanto se permite la asignación de direcciones en ambos extremos de dicho enlace.
La asignación de espacio de direcciones es sólo para el uso por el receptor original de dicha asignación, así como para dispositivos de terceros, siempre y cuando estén operando dentro de la infraestructura de dicho receptor.
Sub-asignar espacio de direcciones a otras partes, por ejemplo, para servicios de banda-ancha, en sustitución de espacio LIR/ISP, es una sub-asignación y por tanto no está permitido.
Por duplicidad, y para evitar confusiones, se elimina la última frase del primer párrafo del apartado 2.3.3.4. Asignaciones a Usuarios Finales
“, pero no para la subdelegación afuera de su organización”.
Por duplicidad, y para evitar confusiones, se elimina el último párrafo del apartado 4.5.5. (Microasignación en IPv6)
“La organización que reciba una micro-asignación no podrá realizar sub-asignaciones con estas direcciones IP.”
Además, el staff de LACNIC corregirá en todo el manual de políticas, todas las versiones de palabras con prefijos “micro”, “sub” u otros similares, que sean incorrectos, mediante el uso de guion medio (“-“).
New textTexto actual:
1.9 Asignar
Asignar significa delegar espacio de direcciones a un usuario final, para su uso específico dentro de la infraestructura de Internet que ellos operan. La asignación de espacio de direcciones debe ser realizada solamente para los propósitos específicos documentados por organizaciones específicas y no para ser subasignadas a otras partes.
Nuevo texto:
1.9 Asignar
Asignar significa delegar espacio de direcciones a un usuario final, para su uso específico dentro de la infraestructura de Internet que ellos operan.
Los enlaces punto-a-punto, VPNs y similares, se consideran como parte de dicha infraestructura y por tanto se permite la asignación de direcciones en ambos extremos de dicho enlace.
La asignación de espacio de direcciones es sólo para el uso por el receptor original de dicha asignación, así como para dispositivos de terceros, siempre y cuando estén operando dentro de la infraestructura de dicho receptor.
Sub-asignar espacio de direcciones a otras partes, por ejemplo, para servicios de banda-ancha, en sustitución de espacio LIR/ISP, es una sub-asignación y por tanto no está permitido.
Por duplicidad, y para evitar confusiones, se elimina la última frase del primer párrafo del apartado 2.3.3.4. Asignaciones a Usuarios Finales
“, pero no para la subdelegación afuera de su organización”.
Por duplicidad, y para evitar confusiones, se elimina el último párrafo del apartado 4.5.5. (Microasignación en IPv6)
“La organización que reciba una micro-asignación no podrá realizar sub-asignaciones con estas direcciones IP.”
Además, el staff de LACNIC corregirá en todo el manual de políticas, todas las versiones de palabras con prefijos “micro”, “sub” u otros similares, que sean incorrectos, mediante el uso de guion medio (“-“).
Additional information-
TimetableInmediato
ReferencesRIPE ha debatido una propuesta similar y se aprobó el cambio, aunque no hay consenso acerca de los cambios aquí propuestos, ya que son textos diferentes.
Presented at:-
En la política de IPv4, a la hora de asignaciones directas de LACNIC a usuarios finales, se habla de subdelegación (2.3.3.4.), y explícitamente se prohíbe a terceras partes.
En la política de IPv6 no hay un texto explícito que lo prohíba, salvo en el caso de las micro-asignaciones (no se podrán realizar sub-asignaciones, 4.5.5.).
Sin embargo, en las definiciones, el punto 1.9 “Asignar”, que afecta a todas las políticas de LACNIC, explícitamente las prohíbe “y no para ser sub-asignadas a otras partes”.
Esta propuesta busca clarificar el texto de la política IPv6 al respecto, y definir mejor el concepto, especialmente teniendo en cuenta nuevos usos de IPv6 (RFC8273).
Se clarifica también que el uso de sub-asignaciones en ISPs, Data Centers y similares, no esta permitido.
Por último, en la lengua Española, no se debe usar “-“ entre un prefijo como sub, micro y similares y la palabra que le sigue, y en el manual de políticas en algunos casos se usa “-“ y en otros no. Se propone el cambio en todo el manual de políticas de todas las palabras que contengan prefijos, para eliminar el “-”.
Rationale (Describe the problem you intend to solve)Cuando se diseñó, en la política, el concepto de asignar/subasignar, no se tuvo en cuenta una práctica muy común en IPv4, que se reproduce e incluso magnifica en IPv6: El uso de direcciones para los enlaces punto-a-punto o VPNs.
En el caso de IPv4, habitualmente se utiliza NAT y por tanto no hay implicaciones. Sin embargo, en aquellos casos de instituciones que no usan NAT, el problema es el mismo que para IPv6.
En el caso de IPv6, en lugar de direcciones únicas, es más habitual el uso de prefijos (/64).
Además, tampoco se tuvo en cuenta el uso de direcciones en hot-spots (cuando no son ISPs, por ejemplo, son asociaciones o redes comunitarias), o el uso de direcciones por parte de invitados o empleados de una entidad (BYOD “Bring Your Own Device”), y muchos otros casos similares.
Otro caso que también se ve impacto, se produce cuando un usuario final contrata a otra compañía para que le proporcione algunos servicios y para ello se requiere desplegar sus propios dispositivos, incluso servidores, equipamiento de red, etc. Por ejemplo, un servicio de vigilancia de seguridad, podría requerir que el contratista proporcione sus propias cámaras, sistema de grabación, e incluso su propio cortafuegos y/o un router para una VPN dedicada, etc. Por supuesto, en muchos casos, este sistema de video-vigilancia podría requerir utilizar espacio de direcciones del usuario final.
Finalmente, el IETF ha aprobado recientemente un concepto de uso de prefijos /64 en interfaces/hosts (RFC8273), en lugar de direcciones únicas, que permite por ejemplo que un usuario se conecte a un hot-spot, reciba un /64, de forma que esta “aislado” (por seguridad, necesidades de legislación, etc.), de otros usuarios y además puede usar máquinas virtuales dentro de su dispositivo con direcciones únicas para cada una de ellas (dentro del mismo /64).
En algunas partes del manual se utiliza el guion medio (“-“), para separar prefijos “sub”, “micro” y similares, y en otras no. Se trata de uniformizarlo.
Current textTexto actual:
1.9 Asignar
Asignar significa delegar espacio de direcciones a un usuario final, para su uso específico dentro de la infraestructura de Internet que ellos operan. La asignación de espacio de direcciones debe ser realizada solamente para los propósitos específicos documentados por organizaciones específicas y no para ser subasignadas a otras partes.
Nuevo texto:
1.9 Asignar
Asignar significa delegar espacio de direcciones a un usuario final, para su uso exclusivamente dentro de la infraestructura que opera, así como para fines de interconexión.
La asignación de espacio de direcciones es sólo para el uso por el receptor original de dicha asignación, así como para dispositivos de terceros, siempre y cuando estén operando dentro de dicha infraestructura.
No está permitida, por tanto, la subasignación a terceros, fuera de dicha infraestructura (por ejemplo, el uso de asignaciones de usuario final para clientes de un ISP o similares), ni proporcionar direccionamiento a terceros en data-centers (y similares).
Por duplicidad, y para evitar confusiones, se elimina la última frase del primer párrafo del apartado 2.3.3.4. Asignaciones a Usuarios Finales
“, pero no para la subdelegación afuera de su organización”.
Por duplicidad, y para evitar confusiones, se elimina el último párrafo del apartado 4.5.5. (Microasignación en IPv6)
“La organización que reciba una micro-asignación no podrá realizar sub-asignaciones con estas direcciones IP.”
Además, el staff de LACNIC corregirá en todo el manual de políticas, todas las versiones de palabras con prefijos “micro”, “sub” u otros similares, que sean incorrectos, eliminando el guion medio (“-“).
New textTexto actual:
1.9 Asignar
Asignar significa delegar espacio de direcciones a un usuario final, para su uso específico dentro de la infraestructura de Internet que ellos operan. La asignación de espacio de direcciones debe ser realizada solamente para los propósitos específicos documentados por organizaciones específicas y no para ser subasignadas a otras partes.
Nuevo texto:
1.9 Asignar
Asignar significa delegar espacio de direcciones a un usuario final, para su uso exclusivamente dentro de la infraestructura que opera, así como para fines de interconexión.
La asignación de espacio de direcciones es sólo para el uso por el receptor original de dicha asignación, así como para dispositivos de terceros, siempre y cuando estén operando dentro de dicha infraestructura.
No está permitida, por tanto, la subasignación a terceros, fuera de dicha infraestructura (por ejemplo, el uso de asignaciones de usuario final para clientes de un ISP o similares), ni proporcionar direccionamiento a terceros en data-centers (y similares).
Por duplicidad, y para evitar confusiones, se elimina la última frase del primer párrafo del apartado 2.3.3.4. Asignaciones a Usuarios Finales
“, pero no para la subdelegación afuera de su organización”.
Por duplicidad, y para evitar confusiones, se elimina el último párrafo del apartado 4.5.5. (Microasignación en IPv6)
“La organización que reciba una micro-asignación no podrá realizar sub-asignaciones con estas direcciones IP.”
Además, el staff de LACNIC corregirá en todo el manual de políticas, todas las versiones de palabras con prefijos “micro”, “sub” u otros similares, que sean incorrectos, eliminando el guion medio (“-“).
Additional information-
TimetableInmediato
ReferencesRIPE ha debatido una propuesta similar y se aprobó el cambio, aunque no hay consenso acerca de los cambios aquí propuestos, ya que son textos diferentes, pero se está discutiendo una versión equivalente a la aquí expuesta. Igualmente se está discutiendo un texto equivalente en AfriNIC y APNIC.
Presented at:LACNIC 31 (06/05/2019)