Autores | |
---|---|
Nombre: Jordi Palet Martinez Email: jordi.palet@consulintel.es Organización: The IPv6 Company |
Nombre: Jordi Palet Martinez Email: jordi.palet@consulintel.es Organización: The IPv6 Company |
Resumen | |
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 ten iendo en cuenta nuevos usos de IPv6 (RFC8273). |
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 ten iendo en cuenta nuevos usos de IPv6 (RFC8273). |
Justificación(Describa el problema que pretende solucionar) | |
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 e mpleados 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 est a "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). |
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 e mpleados 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 est a "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). |
Texto actual | |
Texto 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 (e jemplo, RFC8273), de forma temporal, en un enlace operado por el receptor original de la asignación. Esto incluye, por e jemplo, 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á perm itido. |
Texto 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, d e forma no-permanente, en un enlace operado por el receptor original de la asignación. Esto incluye, por ejemplo, invita dos 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 direccionamient o no puede ser usado (ni directa ni indirectamente) para la propia comunicación. |
Texto nuevo | |
Texto 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 (e jemplo, RFC8273), de forma temporal, en un enlace operado por el receptor original de la asignación. Esto incluye, por e jemplo, 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á perm itido. |
Texto 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, d e forma no-permanente, en un enlace operado por el receptor original de la asignación. Esto incluye, por ejemplo, invita dos 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 direccionamient o no puede ser usado (ni directa ni indirectamente) para la propia comunicación. |
Información adicional | |
- |
- |
Referencias | |
RIPE ha debatido una propuesta similar y se está a la espera de la declaración de consenso por parte de los chairs. |
RIPE ha debatido una propuesta similar y se está a la espera de la declaración de consenso por parte de los chairs. |