Planes de direccionamiento - Revision history

Jincera: /* Tipos de direcciones */

2012-04-01T17:37:03Z

‎Tipos de direcciones

Jincera at 20:22, 16 March 2012

2012-03-16T20:22:31Z

Jincera at 13:22, 16 March 2012

2012-03-16T13:22:33Z

Jincera: New page: {{suivi |Direccionamiento|Aspectos básicos|Unicast-global|Direcciones globales}} == Tiempo de vida de las direcciones == Al generalizar en IPv6 el plan de direccionamiento CIDR, los pr...

2012-03-16T13:11:17Z

New page: {{suivi |Direccionamiento|Aspectos básicos|Unicast-global|Direcciones globales}} == Tiempo de vida de las direcciones == Al generalizar en IPv6 el plan de direccionamiento CIDR, los pr...

New page

{{suivi |Direccionamiento|Aspectos básicos|Unicast-global|Direcciones globales}}

== Tiempo de vida de las direcciones ==

Al generalizar en IPv6 el plan de direccionamiento CIDR, los prefijos quedan, en todos los casos, como propiedad de los operadores. Ya no pueden otorgarse "a perpetuidad" a los dispositivos. Para facilitar la renumeración de una máquina, la asignación de una dirección a una interfaz es temporal; las direcciones IPv6 no se otorgan, sino que se prestan. Se asocia un tiempo de vida a la dirección que indica el tiempo durante el cual la dirección pertenece a la interfaz. Cuando el tiempo de vida se ha agotado, la dirección se invalida, se suprime de la interfaz y queda potencialmente disponible para asignarse a otra interfaz. Una dirección invalida jamás debe ser utilizada en una comunicación. El valor por omisión para el tiempo de vida de una dirección, es de 30 días, pero éste puede prolongarse indefinidamente. La dirección local al enlace (link-local) tiene una duración de vida ilimitada.

La renumeración de une interfaz de un dispositivo consiste en pasar de una dirección a otra. Durante una renumeracion no es aconsejable cambiar bruscamente de dirección; de lo contrario, todas las comunicaciones TCP que la utilizan como identificador de conexión, se cortarían inmediatamente. Esto ocasionaría perturbaciones importantes a nivel de las aplicaciones.

Para facilitar esta transición se implementó un mecanismo de obsolescencia que invalida gradualmente una dirección. Este mecanismo se sirve de la capacidad de asignación de varias direcciones válidas a una misma interfaz. Para elegir la dirección a utilizar, se le asocia un estado que indica en que fase de su tiempo de vida se encuentra con respecto a la interfaz. El primero de esos estados se conoce como ''preferido'': no hay ninguna restricción de uso. Poco antes de su invalidación, la dirección pasa a un estado de ''depreciado''.
<br> En este estado, se desaconseja el uso de la dirección, pero no se prohíbe. La dirección depreciada ya no debe utilizarse como dirección fuente para nuevas comunicaciones (como el establecimiento de una conexión TCP). Sin embargo, aún puede ser dirección fuente para las comunicaciones en curso. Los paquetes recibidos con una dirección destino depreciada, siguen siendo entregados normalmente.

Al tiempo de vida de una dirección, se le asocia una duración en el estado ''preferido''. La figura 3-2 representa los diferentes estados que toma una dirección cuando se asocia a una interfaz.

[[image:CS10.gif]]

== Notación ==

La representación textual de una dirección IPv6 se efectúa dividiendo la palabra de 128 bits, en 8 bloques de 16 bits en formato hexadecimal, separados por el caracter ":". Por ejemplo :

<tt>FEDC:BA98:7654:3210:EDBC:A987:6543:210F</tt>

No es necesario escribir los ceros a la izquierda de un bloque:

<tt>FEDC:0:0:0:400:A987:6543:210F</tt>

Ademas, varios bloques nulos consecutivos, pueden abreviarse como "::". Por ejemplo, la direccion precedente puede escribirse como:

<tt>FEDC::400:A987:6543:210F</tt>

Naturalmente, para en.itar ambigüedades, la abreviación "::" solo puede usarse una vez en una dirección.

La representación de prefijos IPv6 es similar a la notación CIDR especificada en el RFC 1519 para los prefijos IPv4. Así, un prefijo IPv6 sigue el formato representado por la notación:

dirección-ipv6/longitud-del-prefijo-en-bits

Se permite el uso de formatos abreviados con "::"

<tt>3EDC:BA98:7654:3210:0000:0000:0000:0000/64
3EDC:BA98:7654:3210:0:0:0:0/64
3EDC:BA98:7654:3210::/64</tt>

Debe tenerse precaución al utilizar esta notación con prefijos que no terminan en un bloque de 16 bits. Por ejemplo, el prefijo <tt>3EDC:BA98:7654:3::/56</tt> equivale en realidad a <tt>3EDC:BA98:7654:0000::/56</tt> pues se escribe <tt>3EDC:BA98:7654:0003::/56.

Es posible combinar la direccion de una interfaz y la longitud del prefijo de red correspondiente, en una sola notacion.

<tt>3EDC:BA98:7654:3210:945:1321:ABA8:F4E2/64</tt>

Estas representaciones pueden parecer mucho más complejas que con IPv4, pero su asignación está definida por reglas estrictas, lo que facilita su memorización. Además, por las funcionalidades de auto-configuración resulta extremadamente raro, hasta para un ingeniero en redes, manipularlas directamente.

Dicho lo anterior, en ocasiones es necesario manipular las direcciones IPv6 literalmente. El caracter ":" utilizado para separa los bloques, puede crear ambigüedades. Ese es el caso, por ejemplo, con las URL en las que también se puede utilizar para especificar el numero de puerto. Así, la URL:

<tt><nowiki>http://2001:1234:12::1:8000/</nowiki></tt>

podría representar tanto el puerto 8000 en el dispositivo con dirección IPv6 2001:1234:12::1, como el dispositivo 2001:1234:12::1:8000 utilizando el puerto por omisión. Para evitar esta ambigüedad, el RFC 2732 propone delimitar la dirección IPv6 entre "[ ]". Dependiendo del caso, la dirección precedente se escribiría:

<tt><nowiki>http://[2001:1234:12::1]:8000/</nowiki></tt>

o

<tt><nowiki>http://[2001:1234:12::1:8000]/</nowiki></tt>

Esta representación puede extenderse a otros dominios, como X-window o al protocolo de señalización para telefonía SIP.

== Tipos de direcciones ==

IPv6 reconoce tres tipos de direcciones: unicast, multicast y anycast.

El tipo unicast es el mas simple: una dirección de este tipo identifica una interfaz única. Un paquete enviado a ese tipo de dirección, será entregado a la interfaz correspondiente.

Entre las direcciones unicast, se pueden distinguir aquéllas que tienen una cobertura global, es decir, designan sin ambigüedad una máquina en Internet, y las que tienen cobertura local (en el enlace o en el sitio). Estas últimas no pueden ser enrutadas sobre Internet.

Una dirección tipo multicast (difusión restringida) designa a un grupo de interfaces que pertenecen, en general, a nodos distintos que pueden ubicarse en cualquier parte de Internet. Cuando un paquete tiene una dirección destino multicast, éste se envía por la red a todas las interfaces miembros de ese grupo.

Cabe resaltar que desaparecen las direcciones de difusión (''broadcast'') que existían en IPv4; ahora son remplazadas por direcciones tipo multicast que saturan menos una red local basada en conmutadores. La ausencia de direcciones de difusión, facilita el escalamiento de IPv6 en redes conmutadas.

El último tipo, anycast, resulta de la oficialización de propuestas hechas para IPv4 (RFC 1546). Como en el caso multicast, una dirección de tipo anycast designa un grupo de interfaces. La principal diferencia consiste en que cuando un paquete tiene una dirección destino anycast, éste es enviado a alguno de los miembros del grupo, no a todos. El receptor del paquete podría ser, por ejemplo, el más cercano de acuerdo a la métrica de usada por los protocolos de enrutamiento. Esta tipo de dirección es principalmente experimental. Consulte [[_Anycast|Direcciones anycast]].

Algunos tipos de direcciones se identifican por su prefijo (RFC 3513). La tabla siguiente muestra la lista de estos prefijos (fuente: http://www.iana.org/assignments/ipv6-address-space). El bloque "reservado" del prefijo <tt>0::/8</tt> es utilizado por las direcciones llamadas ''especiales'', como una dirección indeterminada, de bucle (''loop''), mapeada, compatible. Se observa que más del 70% del espacio disponible no se ha asignado, lo que permite contar con una gran flexibilidad para el futuro.

{|
!Prefijo IPv6!!Asignar!!Referencia
|-style="background:silver"
|<tt>0000::/8</tt>||[[Otros tipos de direcciones|Reservado para la transición y para ''loopback'']]||RFC 3513
|-
|<tt>0100::/8</tt>||Reservado||RFC 3513
|-style="background:silver"
|<tt>0200::/7</tt>||Reservado (ex [[AOtros tipos de direcciones#Direcciones NSAP|NSAP]])||RFC 4048
|-
|<tt>0400::/6</tt>||Reservado (ex IPX)||RFC 3513
|-style="background:silver"
|<tt>0800::/5</tt>||Reservado||RFC 3513
|-
|<tt>1000::/4</tt>||Reservado||RFC 3513
|-style="background:silver"
|<tt>2000::/3</tt>||[[Unicast-global|Unicast Global]]||RFC 3513
|-
|<tt>4000::/3</tt>||Reservado||RFC 3513
|-style="background:silver"
|<tt>6000::/3</tt>||Reservado||RFC 3513
|-
|<tt>8000::/3</tt>||Reservado||RFC 3513
|-style="background:silver"
|<tt>A000::/3</tt>||Reservado||RFC 3513
|-
|<tt>C000::/3</tt>||Reservado||RFC 3513
|-style="background:silver"
|<tt>E000::/4</tt>||Reservado||RFC 3513
|-
|<tt>F000::/5</tt>||Reservado||RFC 3513
|-style="background:silver"
|<tt>F800::/6</tt>||Reservado||RFC 3513
|-
|<tt>FC00::/7</tt>||[[Site local#ula|Unicast único local]]||RFC 4193
|-style="background:silver"
|<tt>FE00::/9</tt> ||Reservado||RFC 3513
|-
|<tt>FE80::/10</tt>||[[Enlace-local]]||RFC 3513
|-style="background:silver"
|<tt>FEC0::/10</tt>||Reservado||RFC 3879
|-
|<tt>FF00::/8</tt>||Multicast||RFC 3513
|}

En un principio, la IETF había definido las direcciones [[Site local|locales al sitio]] (''site-local'') en el espacio <tt>FEC0::/10</tt>, pero éstas fueron retiradas en las últimas versiones de los estándares.

{{suivi |Direccionamiento|Aspectos básicos|Unicast-global|Direcciones globales}}

@@ Line 85: / Line 85: @@
 |<tt>0100::/8</tt>||Reservado||RFC 3513
 |-style="background:silver"
-|<tt>0200::/7</tt>||Reservado (Ej. [[AOtros tipos de direcciones#Direcciones NSAP|NSAP]])||RFC 4048
+|<tt>0200::/7</tt>||Reservado (Ej. [[Otros tipos de direcciones#Direcciones NSAP|NSAP]])||RFC 4048
 |-
 |<tt>0400::/6</tt>||Reservado (Ej. IPX)||RFC 3513

@@ Line 1: / Line 1: @@
-{{suivi |Direccionamiento|Aspectos básicos|Unicast-global|Direcciones globales}}
+{{esuivi |Direccionamiento|Aspectos básicos|Unicast-global|Direcciones globales}}
 == Tiempo de vida de las direcciones ==
@@ Line 124: / Line 124: @@
 En un principio, la IETF había definido las direcciones [[Site local|locales al sitio]] (''site-local'') en el espacio  <tt>FEC0::/10</tt>, pero éstas fueron retiradas en las últimas versiones de los estándares.
-{{suivi |Direccionamiento|Aspectos básicos|Unicast-global|Direcciones globales}}
+{{esuivi |Direccionamiento|Aspectos básicos|Unicast-global|Direcciones globales}}

@@ Line 24: / Line 24: @@
   <tt>FEDC:0:0:0:400:A987:6543:210F</tt>
-Ademas, varios bloques nulos consecutivos, pueden abreviarse como "::".  Por ejemplo, la direccion precedente puede escribirse como:
+Además, varios bloques nulos consecutivos, pueden abreviarse como "::".  Por ejemplo, la dirección precedente puede escribirse como:
   <tt>FEDC::400:A987:6543:210F</tt>
-Naturalmente, para en.itar ambigüedades, la abreviación  "::" solo puede usarse una vez en una dirección.
+Naturalmente, para evitar ambigüedades, la abreviación  "::" sólo puede usarse una vez en una dirección.
 La representación de prefijos IPv6 es similar a la notación CIDR especificada en el RFC 1519 para los prefijos IPv4.  Así, un prefijo IPv6 sigue el formato representado por la notación:
@@ Line 40: / Line 40: @@
 EDC:BA98:7654:3210::/64</tt>
-Debe tenerse precaución al utilizar esta notación con prefijos que no terminan en un bloque de 16 bits.  Por ejemplo, el prefijo <tt>3EDC:BA98:7654:3::/56</tt> equivale en realidad a <tt>3EDC:BA98:7654:0000::/56</tt> pues se escribe <tt>3EDC:BA98:7654:0003::/56.
+Debe tenerse precaución al utilizar esta notación con prefijos que no terminan en un bloque de 16 bits.  Por ejemplo, el prefijo <tt>3EDC:BA98:7654:3::/56</tt> equivale en realidad a <tt>3EDC:BA98:7654:0000::/56</tt> pues se escribe <tt>3EDC:BA98:7654:0003::/56</tt>.
 Es posible combinar la direccion de una interfaz y la longitud del prefijo de red correspondiente, en una sola notacion.
@@ Line 48: / Line 48: @@
 Estas representaciones pueden parecer mucho más complejas que con  IPv4, pero su asignación está definida por reglas estrictas, lo que facilita su memorización.  Además, por las funcionalidades de auto-configuración resulta extremadamente raro, hasta para un ingeniero en redes, manipularlas directamente.
-Dicho lo anterior, en ocasiones es necesario manipular las direcciones IPv6 literalmente.  El caracter ":" utilizado para separa los bloques, puede crear ambigüedades.  Ese es el caso, por ejemplo, con las URL en las que también se puede utilizar para especificar el numero de puerto.  Así, la URL:
+Dicho lo anterior, en ocasiones es necesario manipular las direcciones IPv6 literalmente.  El caracter ":" utilizado para separa los bloques, puede crear ambigüedades.  Ese es el caso, por ejemplo, con las URL en las que también se puede utilizar para especificar el número de puerto.  Así, la URL:
   <tt><nowiki>http://2001:1234:12::1:8000/</nowiki></tt>
-podría representar tanto el puerto 8000 en el dispositivo con dirección  IPv6 2001:1234:12::1, como el dispositivo 2001:1234:12::1:8000 utilizando el puerto por omisión. Para evitar esta ambigüedad, el RFC 2732 propone delimitar la dirección IPv6 entre "[ ]".  Dependiendo del caso, la dirección precedente se escribiría:
+podría representar tanto el puerto 8000 en el dispositivo con dirección IPv6 <tt>2001:1234:12::1</tt>, como el dispositivo <tt>2001:1234:12::1:8000</tt> utilizando el puerto por omisión. Para evitar esta ambigüedad, el RFC 2732 propone delimitar la dirección IPv6 entre "[ ]".  Dependiendo del caso, la dirección precedente se escribiría:
   <tt><nowiki>http://[2001:1234:12::1]:8000/</nowiki></tt>
@@ Line 74: / Line 74: @@
 Cabe resaltar que desaparecen las direcciones de difusión (''broadcast'') que existían en IPv4; ahora son remplazadas por direcciones tipo multicast que saturan menos una red local basada en conmutadores.  La ausencia de direcciones de difusión, facilita el escalamiento de  IPv6 en redes conmutadas.
-El último tipo, anycast, resulta de la oficialización de propuestas hechas para IPv4 (RFC 1546). Como en el caso multicast, una dirección  de tipo anycast designa un grupo de interfaces.  La principal diferencia consiste en que cuando un paquete tiene una dirección destino anycast, éste es enviado a alguno de los miembros del grupo, no a todos.  El receptor del paquete podría ser, por ejemplo, el más cercano de acuerdo a la métrica de usada por los protocolos de enrutamiento. Esta tipo de dirección es principalmente experimental.  Consulte [[_Anycast|Direcciones anycast]].
+El último tipo, anycast, resulta de la oficialización de propuestas hechas para IPv4 (RFC 1546). Como en el caso multicast, una dirección  de tipo anycast designa un grupo de interfaces.  La principal diferencia consiste en que cuando un paquete tiene una dirección destino anycast, éste es enviado a alguno de los miembros del grupo, no a todos.  El receptor del paquete podría ser, por ejemplo, el más cercano de acuerdo a la métrica de usada por los protocolos de enrutamiento. Esta tipo de dirección es principalmente experimental.  Consulte [[eAnycast|Direcciones anycast]].
 Algunos tipos de direcciones se identifican por su prefijo (RFC 3513).  La tabla siguiente muestra la lista de estos prefijos (fuente: http://www.iana.org/assignments/ipv6-address-space).  El bloque "reservado" del prefijo <tt>0::/8</tt> es utilizado por las direcciones llamadas ''especiales'', como una dirección indeterminada, de bucle (''loop''), mapeada, compatible.  Se observa que más del 70% del espacio disponible no se ha asignado, lo que permite contar con una gran flexibilidad para el futuro.
@@ Line 85: / Line 85: @@
 |<tt>0100::/8</tt>||Reservado||RFC 3513
 |-style="background:silver"
-|<tt>0200::/7</tt>||Reservado (ex [[AOtros tipos de direcciones#Direcciones NSAP|NSAP]])||RFC 4048
+|<tt>0200::/7</tt>||Reservado (Ej. [[AOtros tipos de direcciones#Direcciones NSAP|NSAP]])||RFC 4048
 |-
-|<tt>0400::/6</tt>||Reservado (ex IPX)||RFC 3513
+|<tt>0400::/6</tt>||Reservado (Ej. IPX)||RFC 3513
 |-style="background:silver"
 |<tt>0800::/5</tt>||Reservado||RFC 3513