Direccionamiento VSLM

Direccionamiento El direccionamiento es una funcin clave de los protocolos de red que permite la transmisin de datos entre hosts de la misma
red o en redes diferentes. El protocolo de Internet versin 4 ofrece direccionamiento jerarquico para paquetes que transportan datos. Primero, la Capa de red debe proveer un mecanismo para direccionar estos dispositivos finales. Si las secciones individuales de datos deben dirigirse a un dispositivo final, este dispositivo debe tener una direccin nica. En una red IPv4, cuando se agrega esta direccin a un dispositivo, al dispositivo se lo denomina host.
Enrutamiento: Es seleccionar las mejores rutas posibles y dirigir paquetes hacia su destino. Es la funcin de buscar un camino para un paquete entre todos los posibles en una red. El proceso de enviar un paquete IP sobre otra red se llama enrutamiento o reenvo de un paquete IP. Un computador que ha sido dedicado a la tarea de enrutar o reenviar paquetes IP se llama un "router o enrutador IP".
Encapsulamiento El encapsulamiento envuelve los datos con la informacin de protocolo necesaria antes de transitar por la red. As, mientras la informacin se mueve hacia abajo por las capas del modelo OSI, cada capa aade un encabezado, y un trailer si es necesario, antes de pasarla a una capa inferior. Los encabezados y trailers contienen informacin de control para los dispositivos de red y receptores para asegurar la apropiada entrega de de los datos y que el receptor interprete correctamente lo que recibe.
Paso 1: los datos de usuario son enviados por una aplicacin a la capa de aplicacin. Paso 2: La capa de aplicacin aade el encabezado (layer 7 Header) a los datos, el encabezado y los datos originales pasan a la capa de presentacin. Paso 3: La capa de presentacin recibe los datos provenientes de la capa superior, incluyendo el encabezado agregado, y los trata como slo datos, aade su encabezado a los datos, y los pasa a la capa de sesin Paso 4: la capa de sesin recibe los datos y aade su encabezado, lo pasa a la capa de transporte. Paso 5: la capa de transporte recibe los datos y aade su encabezado, pasa los datos a la capa inferior. Paso 6: la capa de red aade su encabezado y los pasa a la capa de enlace de datos. Paso 7: la capa de enlace de datos aade el encabezado y un trailer (cola) a los datos, usualmente es un Frame Check Sequence, que usa el receptor para detectar si los datos enviados estn o no en error. Esto envuelve los datos que son pasados a la capa fsica. Paso 8: la capa fsica entonces transmite los bits hacia el medio de red.
Desencapsulamiento Es el proceso inverso, a medida que el paquete pasa de capa en capa, cada una de estas le quita un header al paquete, hasta que la informacin llega a la capa de aplicacin. Cuando el paquete llega al host destino es procesado en la Capa 3. El host examina la direccin de destino para verificar que el paquete fue direccionado a ese dispositivo. Si la direccin es correcta, el paquete es desencapsulado por la capa de Red y la PDU de la Capa 4 contenida en el paquete pasa hasta el servicio adecuado en la capa de transporte.
IPv4
El Internet Protocol version 4 (IPv4) (en espaol: Protocolo de Internet versin 4) es la cuarta versin del protocolo Internet Protocol (IP), y la primera en ser implementada a gran escala. Definida en el RFC 791. IPv4 usa direcciones de 32 bits, limitndola a = 4.294.967.296 direcciones nicas, muchas de las cuales estn dedicadas a redes locales (LANs)[cita requerida]. Por el crecimiento enorme que ha tenido Internet (mucho ms de lo que esperaba, cuando se dise IPv4), combinado con el hecho de que hay desperdicio de direcciones en muchos casos (ver abajo), ya hace varios aos se vio que escaseaban las direcciones IPv4. Esta limitacin ayud a estimular el impulso hacia IPv6, que est actualmente en las primeras fases de implantacin, y se espera que termine reemplazando a IPv4. Las direcciones disponibles en la reserva global de IANA pertenecientes al protocolo IPv4 se agotaron el jueves 3 de Febrero de 2011 oficialmente1 Los Registros Regionales de Internet deben, desde ahora, manejarse con sus propias reservas, que se estima, alcanzaran hasta Septiembre de 2011 Actualmente no quedan direcciones IPv4 disponibles para compra, por ende se est en la forzosa y prioritaria obligacion de migrar a IPv6, Los sistemas operativos Windows Vista, 7, 8, Unix/like (Gnu/linux, Unix, Mac OSX), BSD entre otros, tienen soporte nato para IPv6, mientras que Windows XP requiere utilizar el prompt y digitar ipv6 install, para instalarlo, y sistemas anteriores no tienen soporte para este.
Desperdicio de direcciones
El desperdicio de direcciones IPv4 se debe a varios factores. Uno de los principales es que inicialmente no se consider el enorme crecimiento que iba a tener Internet; se asignaron bloques de direcciones grandes (de 16,271 millones de direcciones) a pases, e incluso a empresas. Otro motivo de desperdicio es que en la mayora de las redes, exceptuando las ms pequeas, resulta conveniente dividir la red en subredes. Dentro de cada subred, la primera y la ltima direccin no son utilizables; de todos modos no siempre se utilizan todas las direcciones restantes. Por ejemplo, si en una subred se quieren acomodar 80 hosts, se necesita una subred de 128 direcciones (se tiene que redondear a la siguiente potencia de base 2); en este ejemplo, las 48 direcciones restantes ya no se utilizan.
IPv6
Saltar a: navegacin, bsqueda
El Internet Protocol version 6 (IPv6) (en espaol: Protocolo de Internet versin 6) es una versin del protocolo Internet Protocol (IP), definida en el RFC 2460 y diseada para reemplazar a Internet Protocol version 4 (IPv4) RFC 791, que actualmente est implementado en la gran mayora de dispositivos que acceden a Internet. Diseado por Steve Deering de Xerox PARC y Craig Mudge, IPv6 est destinado a sustituir a IPv4, cuyo lmite en el nmero de direcciones de red admisibles est empezando a restringir el crecimiento de Internet y su uso, especialmente en China, India, y otros pases asiticos densamente poblados. El nuevo estndar mejorar el servicio globalmente; por ejemplo, proporcionar a futuras celdas telefnicas y dispositivos mviles sus direcciones propias y permanentes. A principios de 2010, quedaban menos del 10% de IPs sin asignar.1 En la semana del 3 de febrero del 2011, la IANA (Agencia Internacional de Asignacin de Nmeros de Internet, por sus siglas en ingls) entreg el ltimo bloque de direcciones disponibles (33 millones) a la organizacin encargada de asignar IPs en Asia, un mercado que est en auge y no tardar en consumirlas todas. IPv4 posibilita 4.294.967.296 (232) direcciones de red diferentes, un nmero inadecuado para dar una direccin a cada persona del planeta, y mucho menos a cada vehculo, telfono, PDA, etctera. En cambio, IPv6 admite 340.282.366.920.938.463.463.374.607.431.768.211.456 (2128 o 340 sextillones de direcciones) cerca de 6,7 1017 (670 mil billones) de direcciones por cada milmetro cuadrado de la superficie de La Tierra. Otra va para la popularizacin del protocolo es la adopcin de este por parte de instituciones. El gobierno de los Estados Unidos orden el despliegue de IPv6 por todas sus agencias federales en el ao 20082
Contenido

1 Motivacin y orgenes de los IP 2 Cambios y nuevas caractersticas o 2.1 Capacidad extendida de direccionamiento o 2.2 Autoconfiguracin de direcciones libres de estado o 2.3 Multicast o 2.4 Seguridad de Nivel de Red obligatoria o 2.5 Procesamiento simplificado en los routers o 2.6 Movilidad o 2.7 Soporte mejorado para las extensiones y opciones o 2.8 Jumbogramas 3 Direccionamiento IPv6 o 3.1 Notacin para las direcciones IPv6 o 3.2 Identificacin de los tipos de direcciones 4 Paquete IPv6 o 4.1 Cabecera Fija o 4.2 Cabeceras de extensin o 4.3 Carga til 5 IPv6 y el Sistema de Nombres de Dominio o 5.1 Mecanismos de transicin a IPv6
6 Despliegue de IPv6 7 Anuncios importantes sobre IPv6 8 En Colombia 9 Vase tambin 10 Referencias 11 Vase tambin 12 Enlaces externos
Motivacin y orgenes de los IP

Durante la primera dcada de operacin de Internet basado en TCP/IP, a fines de los 80s, se hizo aparente que se necesitaba desarrollar mtodos para conservar el espacio de direcciones. A principios de los 90s, incluso despus de la introduccin del rediseo de redes sin clase, se hizo claro que no sera suficiente para prevenir el agotamiento de las direcciones IPv4 y que se necesitaban cambios adicionales. A comienzos de 1992, circulaban varias propuestas de sistemas y a finales de 1992, la IETF anunci el llamado para white papers (RFC 1550) y la creacin de los grupos de trabajo de "IP de prxima generacin" ("IP Next Generation") o (IPng). IPng fue propuesto por el Internet Engineering Task Force (IETF) el 25 de julio de 1994, con la formacin de varios grupos de trabajo IPng. Hasta 1996, se publicaron varios RFCs definiendo IPv6, empezando con el RFC 2460. La discusin tcnica, el desarrollo e introduccin de IPv6 no fue sin controversia. Incluso el diseo ha sido criticado por la falta de interoperabilidad con IPv4 y otros aspectos, por ejemplo por el cientfico de computacin D. J. Bernstein.3 Incidentalmente, IPng (IP Next Generation) no pudo usar la versin nmero 5 (IPv5) como sucesor de IPv4, ya que sta haba sido asignada a un protocolo experimental orientado al flujo de streaming que intentaba soportar voz, video y audio. Se espera ampliamente que IPv6 sea soportado en conjunto con IPv4 en el futuro cercano. Los nodos solo-IPv4 no son capaces de comunicarse directamente con los nodos IPv6, y necesitarn ayuda de un intermediario.
Cambios y nuevas caractersticas

En muchos aspectos, IPv6 es una extensin conservadora de IPv4. La mayora de los protocolos de transporte -y aplicacin- necesitan pocos o ningn cambio para operar sobre IPv6; las excepciones son los protocolos de aplicacin que integran direcciones de capa de red, como FTP o NTPv3, NTPv4. IPv6 especifica un nuevo formato de paquete, diseado para minimizar el procesamiento del encabezado de paquetes. Debido a que las cabeceras de los paquetes IPv4 e IPv6 son significativamente distintas, los dos protocolos no son interoperables.
Algunos de los cambios de IPv4 a IPv6 ms relevantes son:
Capacidad extendida de direccionamiento
Una ilustracin de una direccin IP (versin 6), en hexadecimal y binario.
El inters de los diseadores era que direcciones ms largas permiten una entrega jerrquica, sistemtica y en definitiva mejor de las direcciones y una eficiente agregacin de rutas. Con IPv4, se desplegaron complejas tcnicas de Classless Interdomain Routing (CIDR) para utilizar de mejor manera el pequeo espacio de direcciones. El esfuerzo requerido para reasignar la numeracin de una red existente con prefijos de rutas distintos es muy grande, como se discute en RFC 2071 y RFC 2072. Sin embargo, con IPv6, cambiando el prefijo anunciado por unos pocos routers es posible en principio reasignar la numeracin de toda la red, ya que los identificadores de nodos (los 64 bits menos significativos de la direccin) pueden ser auto-configurados independientemente por un nodo. El tamao de una subred en IPv6 es de 264 (mscara de subred de 64-bit), el cuadrado del tamao de la Internet IPv4 entera. As, las tasas de utilizacin del espacio de direcciones ser probablemente menor en IPv6, pero la administracin de las redes y el ruteo sern ms eficientes debido a las decisiones de diseo inherentes al mayor tamao de las subredes y la agregacin jerrquica de rutas.
Autoconfiguracin de direcciones libres de estado
Los nodos IPv6 pueden configurarse a s mismos automticamente cuando son conectados a una red ruteada en IPv6 usando los mensajes de descubrimiento de routers de ICMPv6. La primera vez que son conectados a una red, el nodo enva una solicitud de router de link-local usando multicast (router solicitacin) pidiendo los parmetros de configuracin; y si los routers estn configurados para esto, respondern este requerimiento con un "anuncio de router" (router advertisement) que contiene los parmetros de configuracin de capa de red. Si la autoconfiguracin de direcciones libres de estado no es adecuada para una aplicacin, es posible utilizar Dynamic Host Configuration Protocol para IPv6 (DHCPv6) o bien los nodos pueden ser configurados en forma esttica. Los routers presentan un caso especial de requerimientos para la configuracin de direcciones, ya que muchas veces son la fuente para informacin de autoconfiguracin,
como anuncios de prefijos de red y anuncios de router. La configuracin sin estado para routers se logra con un protocolo especial de renumeracin de routers.
Multicast Artculo principal: Multicast.
Multicast, la habilidad de enviar un paquete nico a destinos mltiples es parte de la especificacin base de IPv6. Esto es diferente a IPv4, donde es opcional (aunque usualmente implementado). IPv6 no implementa broadcast, que es la habilidad de enviar un paquete a todos los nodos del enlace conectado. El mismo efecto puede lograrse enviando un paquete al grupo de multicast de enlace-local todos los nodos (all hosts). Por lo tanto, no existe el concepto de una direccin de broadcast y as la direccin ms alta de la red (la direccin de broadcast en una red IPv4) es considerada una direccin normal en IPv6. Muchos ambientes no tienen, sin embargo, configuradas sus redes para rutear paquetes multicast, por lo que en stas ser posible hacer "multicasting" en la red local, pero no necesariamente en forma global. El multicast IPv6 comparte protocolos y caractersticas comunes con IPv4, pero tambin incorpora cambios y mejoras. Incluso cuando se le asigne a una organizacin el ms pequeo de los prefijos de ruteo global IPv6, sta tambin recibe la posibilidad de usar uno de los 4.2 billones de grupos multicast IPv6 ruteables de fuente especfica para asignarlos para aplicaciones multicast intra-dominio o entre-dominios (RFC 3306). En IPv4 era muy difcil para una organizacin conseguir incluso un nico grupo multicast ruteable entre-dominios y la implementacin de las soluciones entre-dominios eran anticuadas (RFC 2908). IPv6 tambin soporta nuevas soluciones multicast, incluyendo Embedded Rendezvous Point (RFC 3956), el que simplifica el despliegue de soluciones entre dominios.
Seguridad de Nivel de Red obligatoria
Internet Protocol Security (IPsec), el protocolo para cifrado y autenticacin IP forma parte integral del protocolo base en IPv6. El soporte IPsec es obligatorio en IPv6; a diferencia de IPv4, donde es opcional (pero usualmente implementado). Sin embargo, actualmente no se est usando normalmente IPsec excepto para asegurar el trfico entre routers de BGP IPv6.
Procesamiento simplificado en los routers
Se hicieron varias simplificaciones en la cabecera de los paquetes, as como en el proceso de reenvo de paquetes para hacer el procesamiento de los paquetes ms simple y por ello ms eficiente. En concreto,
El encabezado del paquete en IPv6 es ms simple que el utilizado en IPv4, as los campos que son raramente utilizados han sido movidos a opciones separadas; en efecto, aunque las direcciones en IPv6 son 4 veces ms largas, el encabezado IPv6 (sin opciones) es solamente el doble de largo que el encabezado IPv4 (sin opciones).
Los routers IPv6 no hacen fragmentacin. Los nodos IPv6 requieren ya sea hacer descubrimiento de MTU, realizar fragmentacin extremo a extremo o enviar paquetes menores al MTU mnimo de IPv6 de 1280 bytes. El encabezado IPv6 no est protegido por una suma de comprobacin (checksum); la proteccin de integridad se asume asegurada tanto por el checksum de capa de enlace y por un checksum de nivel superior (TCP, UDP, etc.). En efecto, los routers IPv6 no necesitan recalcular la suma de comprobacin cada vez que algn campo del encabezado (como el contador de saltos o Tiempo de Vida) cambian. Esta mejora puede ser menos necesaria en routers que utilizan hardware dedicado para computar este clculo y as pueden hacerlo a velocidad de lnea (wirespeed), pero es relevante para routers por software. El campo Tiempo de Vida de IPv4, conocido como TTL (Time To Live), pasa a llamarse Lmite de saltos, reflejando el hecho de que ya no se espera que los routers computen el tiempo en segundos que tarda en atravesarlo (que en cualquier caso siempre resulta menor de 1 segundo). Se simplifica como el nmero de saltos entre routers que se permita realizar al paquete IPv6.
Movilidad
A diferencia de IPv4 mvil, IPv6 mvil (MIPv6) evita el ruteo triangular y por lo tanto es tan eficiente como el IPv6 normal. Los routers IPv6 pueden soportar tambin Movilidad de Red (NEMO, por Network Mobility) (RFC 3963), que permite que redes enteras se muevan a nuevos puntos de conexin de routers sin reasignacin de numeracin. Sin embargo, ni MIPv6 ni MIPv4 o NEMO son ampliamente difundidos hoy, por lo que esta ventaja es ms bien terica.
Soporte mejorado para las extensiones y opciones
Los cambios en la manera en que se codifican las opciones de la cabecera IP permiten lmites menos rigurosos en la longitud de opciones, y mayor flexibilidad para introducir nuevas opciones en el futuro.
Jumbogramas
IPv4 limita los paquetes a 64 KiB de carga til. IPv6 tiene soporte opcional para que los paquetes puedan superar este lmite, los llamados jumbogramas, que pueden ser de hasta 4 GiB. El uso de jumbogramas puede mejorar mucho la eficiencia en redes de altos MTU. El uso de jumbogramas est indicado en el encabezado opcional Jumbo Payload Option.
Direccionamiento IPv6
Artculo principal: Direccin IPv6.
El cambio ms grande de IPv4 a IPv6 es la longitud de las direcciones de red. Las direcciones IPv6, definidas en el RFC 2373 y RFC 2374 pero fue redefinida en abril de 2003 en la RFC 3513, son de 128 bits; esto corresponde a 32 dgitos hexadecimales, que se utilizan normalmente para escribir las direcciones IPv6, como se describe en la siguiente seccin.
El nmero de direcciones IPv6 posibles es de 2128 3.4 x 1038. Este nmero puede tambin representarse como 1632, con 32 dgitos hexadecimales, cada uno de los cuales puede tomar 16 valores (vase combinatoria). En muchas ocasiones las direcciones IPv6 estn compuestas por dos partes lgicas: un prefijo de 64 bits y otra parte de 64 bits que corresponde al identificador de interfaz, que casi siempre se genera automticamente a partir de la direccin MAC de la interfaz a la que est asignada la direccin.
Notacin para las direcciones IPv6
Las direcciones IPv6, de 128 bits de longitud, se escriben como ocho grupos de cuatro dgitos hexadecimales. Por ejemplo,
2001:0db8:85a3:08d3:1319:8a2e:0370:7334
es una direccin IPv6 vlida. Se puede comprimir un grupo de cuatro dgitos si ste es nulo (es decir, toma el valor "0000"). Por ejemplo,
2001:0db8:85a3:0000:1319:8a2e:0370:7344 ---2001:0db8:85a3::1319:8a2e:0370:7344
Siguiendo esta regla, si ms de dos grupos consecutivos son nulos, tambin pueden comprimirse como "::". Si la direccin tiene ms de una serie de grupos nulos consecutivos la compresin slo se permite en uno de ellos. As, las siguientes son representaciones posibles de una misma direccin:
2001:0DB8:0000:0000:0000:0000:1428:57ab 2001:0DB8:0000:0000:0000::1428:57ab 2001:0DB8:0:0:0:0:1428:57ab 2001:0DB8:0::0:1428:57ab 2001:0DB8::1428:57ab
son todas vlidas y significan lo mismo, pero

2001::25de::cade ---
no es vlida porque no queda claro cuntos grupos nulos hay en cada lado. Los ceros iniciales en un grupo tambin se pueden omitir:
2001:0DB8:02de::0e13 2001:DB8:2de::e13
Si la direccin es una direccin IPv4 empotrada, los ltimos 32 bits pueden escribirse en base decimal, as:
::ffff:192.168.89.9 ::ffff:c0a8:5909
No se debe confundir con:

::192.168.89.9 ::c0a8:5909
El formato ::ffff:1.2.3.4 se denomina direccin IPv4 mapeada, y el formato ::1.2.3.4 direccin IPv4 compatible. Las direcciones IPv4 pueden ser transformadas fcilmente al formato IPv6. Por ejemplo, si la direccin decimal IPv4 es 135.75.43.52 (en hexadecimal, 0x874B2B34), puede ser convertida a 0000:0000:0000:0000:0000:0000:874B:2B34 o::874B:2B34. Entonces, uno puede usar la notacin mixta direccin IPv4 compatible, en cuyo caso la direccin debera ser::135.75.43.52. Este tipo de direccin IPv4 compatible casi no est siendo utilizada en la prctica, aunque los estndares no la han declarado obsoleta. Cuando lo que se desea es identificar un rango de direcciones diferenciable por medio de los primeros bits, se aade este nmero de bits tras el carcter de barra "/". Por ejemplo:
2001:0DB8::1428:57AB/96 sera equivalente a 2001:0DB8:: 2001:0DB8::874B:2B34/96 sera equivalente a 2001:0DB8:: y por supuesto tambin a 2001:0DB8::1428:57AB/96
Identificacin de los tipos de direcciones
Los tipos de direcciones IPv6 pueden identificarse tomando en cuenta los rangos definidos por los primeros bits de cada direccin.
::/128 La direccin con todo ceros se utiliza para indicar la ausencia de direccin, y no se asigna ningn nodo. ::1/127 La direccin de loopback es una direccin que puede usar un nodo para enviarse paquetes a s mismo (corresponde con 127.0.0.1 de IPv4). No puede asignarse a ninguna interfaz fsica. ::1.2.3.4/96 La direccin IPv4 compatible se usa como un mecanismo de transicin en las redes duales IPv4/IPv6. Es un mecanismo que no se usa. ::ffff:0:0/96 La direccin IPv4 mapeada se usa como mecanismo de transicin en terminales duales. fe80::/10 El prefijo de enlace local (en ingls link local) especfica que la direccin slo es vlida en el enlace fsico local.
fec0:: El prefijo de emplazamiento local (en ingls site-local prefix) especfica que la direccin slo es vlida dentro de una organizacin local. La RFC 3879 lo declar obsoleto, estableciendo que los sistemas futuros no deben implementar ningn soporte para este tipo de direccin especial. Se deben sustituir por direcciones Local IPv6 Unicast. ff00::/8 El prefijo de multicast. Se usa para las direcciones multicast.
Hay que resaltar que no existen las direcciones de difusin (en ingls broadcast) en IPv6, aunque la funcionalidad que prestan puede emularse utilizando la direccin multicast FF01::1/128, denominada todos los nodos (en ingls all nodes)
Paquete IPv6
Un paquete en IPv6 est compuesto principalmente de dos partes: la cabecera (que tiene una parte fija y otra con las opciones) y la carga til (los datos).
Cabecera Fija
Los primeros 40 bytes (320 bits) son la cabecera del paquete y contiene los siguientes campos:
Offse t del Octet o
Bit 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 Offse 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 t 0 4 8 C 10 14 0 32 64 96 Direccin de Origen 128 160 Versi Clase de Trfico n Longitud del campo de datos Etiqueta de Flujo Cabecera Siguiente Lmite de Saltos
18 1C 20 24
192 224 Direccin de Destino 256 288
direcciones de origen (128 bits) direcciones de destino (128 bits) versin del protocolo IP (4 bits) clase de trfico (8 bits, Prioridad del Paquete) Etiqueta de flujo (20 bits, manejo de la Calidad de Servicio), Longitud del campo de datos (16 bits) Cabecera siguiente (8 bits) Lmite de saltos (8 bits, Tiempo de Vida).
Hay dos versiones de IPv6 levemente diferentes. La ahora obsoleta versin inicial, descrita en el RFC 1883, difiere de la actual versin propuesta de estndar, descrita en el RFC 2460, en dos campos: hay 4 bits que han sido reasignados desde "etiqueta de flujo" (flow label) a "clase de trfico" (traffic class). El resto de diferencias son menores. En IPv6 la fragmentacin se realiza slo en el nodo origen del paquete, al contrario que en IPv4 en donde los routers pueden fragmentar un paquete. En IPv6, las opciones tambin desaparecen de la cabecera estndar y son especificadas por el campo "Cabecera Siguiente" (Next Header), similar en funcionalidad en IPv4 al campo Protocolo. Un ejemplo: en IPv4 uno aadira la opcin "ruta fijada desde origen" (Strict Source and Record Routing) a la cabecera IPv4 si quiere forzar una cierta ruta para el paquete, pero en IPv6 uno modificara el campo "Cabecera Siguiente" indicando que viene una cabecera de encaminamiento. La cabecera de encaminamiento podr entonces especificar la informacin adicional de encaminamiento para el paquete, e indicar que, por ejemplo, la cabecera TCP ser la siguiente. Este procedimiento es anlogo al de AH y ESP en IPsec para IPv4 (que aplica a IPv6 de igual modo, por supuesto).
Cabeceras de extensin
El uso de un formato flexible de cabeceras de extensin opcionales es una idea innovadora que permite ir aadiendo funcionalidades de forma paulatina. Este diseo aporta gran eficacia y flexibilidad ya que se pueden definir en cualquier momento a medida que se vayan necesitando entre la cabecera fija y la carga til. Hasta el momento, existen 8 tipos de cabeceras de extensin, donde la cabecera fija y las de extensin opcionales incluyen el campo de cabecera siguiente que identifica el tipo de cabeceras de extensin que viene a continuacin o el identificador del protocolo de nivel superior. Luego las cabeceras de extensin se van encadenando utilizando el campo de cabecera siguiente que aparece tanto en la cabecera fija como en cada una de las citadas cabeceras de extensin. Como resultado de la secuencia anterior, dichas cabeceras de extensin se tienen que procesar en el mismo orden en el que aparecen en
el datagrama. La Cabecera principal, tiene a diferencia de la cabecera de la versin IPv4 un tamao fijo de 40 octetos.Especfica para asignarlos para aplicaciones multicast intra-dominio o entre-dominios (RFC 3306). En IPv4 era muy difcil para una organizacin co Todas o parte de estas cabeceras de extensin tienen que ubicarse en el datagrama en el orden especificado:
Cabecera de Extensin Tipo Tamao Descripcin RFC
Opciones salto a salto (Hop-By0 Hop Options)
Contiene datos que deben ser variable examinados por cada nodo a travs RFC 2460 de la ruta de envo de un paquete. Mtodos para especificar la forma RFC 2460, variable de rutear un datagrama. (Usado con RFC 6275, IPv6 mvil) RFC 5095 64 bits Contiene parmetros para la fragmentacin de los datagramas. RFC 2460
Ruteo (Routing)
43
Cabecera de fragmentacin (Fragment) Cabecera de autenticacin (Authentication Header (AH)) Encapsulado de seguridad de la carga til (Encapsulating Security Payload (ESP)) Opciones para el destino (Destination Options) No Next Header
44
51
Contiene informacin para verificar variable la autenticacin de la mayor parte RFC 4302 de los datos del paquete (Ver IPsec) Lleva la informacin cifrada para comunicacin segura (Ver IPsec).
50
variable
RFC 4303
60
Informacin que necesita ser variable examinada solamente por los nodos RFC 2460 de destino del paquete. vaco Indica que no hay ms cabeceras RFC 2460
59
Cada cabecera de extensin debe aparecer como mucho una sola vez, salvo la cabecera de opcin destino, que puede aparecer como mucho dos veces, una antes de la cabecera ruteo y otra antes de la cabecera de la capa superior.
Carga til
La carga til del paquete puede tener un tamao de hasta 64 KB en modo estndar, o mayor con una opcin de carga jumbo (jumbo payload) en el encabezado opcional HopBy-Hop.
La fragmentacin es manejada solamente en el host que enva la informacin en IPv6: los routers nunca fragmentan un paquete y los hosts se espera que utilicen el Path MTU discovery.
IPv6 y el Sistema de Nombres de Dominio

Las direcciones IPv6 se representan en el Sistema de Nombres de Dominio (DNS) mediante registros AAAA (tambin llamados registros de quad-A, por tener una longitud cuatro veces la de los registros A para IPv4) El concepto de AAAA fue una de las dos propuestas al tiempo que se estaba diseando la arquitectura IPv6. La otra propuesta utilizaba registros A6 y otras innovaciones como las etiquetas de cadena de bits (bit-string labels) y los registros DNAME. Mientras que la idea de AAAA es una simple generalizacin del DNS IPv4, la idea de A6 fue una revisin y puesta a punto del DNS para ser ms genrico, y de ah su complejidad. La RFC 3363 recomienda utilizar registros AAAA hasta tanto se pruebe y estudie exhaustivamente el uso de registros A6. La RFC 3364 realiza una comparacin de las ventajas y desventajas de cada tipo de registro.
Mecanismos de transicin a IPv6 Artculo principal: Mecanismos de transicin IPv6.
Ante el agotamiento de las direcciones IPv4, y los problemas que este est ocasionando ya, sobretodo en los pases emergentes de Asia como India o China, el cambio a IPv6 ya ha comenzado. Se espera que convivan ambos protocolos durante un ao, aunque se piensa que la implantacin mundial y total en internet de IPv6 se har realidad hacia finales de 2012, dada la celeridad con la que se estn agotando las direcciones IPv4. La red no podr aguantar mucho ms sin el cambio, y de no realizarse pronto este las consecuencias podran ser muy graves. [cita requerida] Existe una serie de mecanismos que permitirn la convivencia y la migracin progresiva tanto de las redes como de los equipos de usuario. En general, los mecanismos de transicin pueden clasificarse en tres grupos:

Doble pila Tneles Traduccin
La doble pila hace referencia a una solucin de nivel IP con doble pila (RFC 4213), que implementa las pilas de ambos protocolos, IPv4 e IPv6, en cada nodo de la red. Cada nodo con doble pila en la red tendr dos direcciones de red, una IPv4 y otra IPv6.

A favor: Fcil de desplegar y extensamente soportado. En contra: La topologa de red requiere dos tablas de encaminamiento y dos procesos de encaminamiento. Cada nodo en la red necesita tener actualizadas las dos pilas.
Los tneles permiten conectarse a redes IPv6 "saltando" sobre redes IPv4. Estos tneles trabajan encapsulando los paquetes IPv6 en paquetes IPv4 teniendo como siguiente capa
IP el protocolo nmero 41, y de ah el nombre proto-41. De esta manera, se pueden enviar paquetes IPv6 sobre una infraestructura IPv4. Hay muchas tecnologas de tneles disponibles. La principal diferencia est en el mtodo que usan los nodos encapsuladores para determinar la direccin a la salida del tnel. La traduccin es necesaria cuando un nodo que slo soporta IPv4 intenta comunicar con un nodo que slo soporta IPv6. Los mecanismos de traduccin se pueden dividir en dos grupos basados en si la informacin de estado est guardada o no:

Con estado: NAT-PT (RFC 2766), TCP-UDP Relay (RFC 3142), Socks-based Gateway (RFC 3089) Sin estado: Bump-in-the-Stack, Bump-in-the-API (RFC 276)
Despliegue de IPv6
Varios de los mecanismos mencionados ms arriba se han implementado para acelerar el despliegue de IPv6. Los distintos servicios de control de Internet han ido incorporando soporte para IPv6, as como los controladores de los dominios de nivel superior (o ccTLD, en ingls).
Anuncios importantes sobre IPv6
En 2003, Nihon Keizai Shimbun informa que Japn, China y Corea del Sur han tomado la determinacin de convertirse en las naciones lderes en la tecnologa de Internet, que conjuntamente han dado forma parcialmente al desarrollo de IPv6, y que lo adoptarn completamente a partir de 2005. ICANN anunci el 20 de julio de 2004 que los registros AAAA de IPv6 de cdigo de pas para Japn (.jp) y Corea (.kr) ya son visibles en los servidores raz de DNS.4 El registro IPv6 para Francia (.fr) fue aadido poco despus.5 El 4 de febrero de 2008 se aade a los servidores raz de la red (Master Address books) direcciones en IP versin 6 (IPv6). Esto significa que por primera vez las mquinas que utilicen IPv6 pueden encontrarse una a la otra sin la participacin de toda la tecnologa IPv4.6 Desde el 2006 muchos sistemas operativos han estado trabajando en IPv6 paralelamente con IPv4, sistemas como GNU/Linux, Mac,7 Unix y Windows.8 El 8 de junio de 2011 los principales proovedores de servicios de Internet (Telefnica, Claro y Nextel) realizan una prueba para comprobar el funcionamiento de esta tecnologa El 6 de junio de 2012 a las 00:00 GMT, los principales proveedores de servicios de Internet y Compaas web (Akamai, AT&T, Cisco, Comcast, D-Link, Facebook, Free Telecom, Google, Internode, Kddi, Limelight, Microsoft Bing, Time Warner, XS4ALL, Yahoo!, etc) habilitaron permanentemente IPv6 en sus productos y servicios .
En Colombia
En Colombia, la Red Nacional Acadmica de Tecnologa Avanzada (RENATA), se ha convertido en la pionera en el uso de IPv6, Telefnica, como proveedor del servicio en Colombia, culmin con xito la implementacin de la primera red nacional funcionando bajo el protocolo IPv6.
3.1. Formato de la Cabecera Internet 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Versin| IHL | Tipo Servicio | Longitud Total | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identificacin |Flags| Posicin | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Tiempo de Vida | Protocolo | Suma de Control de Cabecera | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Direccin de Origen | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Direccin de Destino | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opciones | Relleno | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ejemplo de Cabecera de un Datagrama Internet Figura 4. Ntese que cada marca (-) corresponde a una posicin de un bit. Versin: 4 bits. El campo Versin describe el formato de la cabecera internet. IHL: 4 bits. Longitud de la Cabecera Internet (Internet Header Length), es la longitud de la cabecera en palabras de 32 bits, y por tanto apunta al comienzo de los datos. Ntese que el valor mnimo para una cabecera correcta es 5. Tipo de Servicio: 8 bits. El Tipo de Servicio proporciona una indicacin de los parmetros abstractos de la calidad de servicio deseada. Estos parmetros se usarn para guiar la seleccin de los parmetros de servicio reales al transmitir un datagrama a travs de una red en particular. Algunas redes ofrecen prioridad de servicio, la cual trata de algn modo el trfico de alta prioridad como ms importante que el resto del trfico (generalmente aceptando slo trfico por encima de cierta prioridad en momentos de sobrecarga). La eleccin ms comn es un compromiso a tres niveles entre baja demora, alta fiabilidad, y alto rendimiento. Bits 0-2: Prioridad. Bit 3: 0 = Demora Normal, 1 = Baja Demora. Bit 4: 0 = Rendimiento Normal , 1 = Alto rendimiento. Bit 5: 0 = Fiabilidad Normal , 1 = Alta fiabilidad.] Bits 6-7: Reservado para uso futuro.
0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | | | | | | | | PRECEDENCIA | D | T | R | 0 | 0 | | | | | | | | +-----+-----+-----+-----+-----+-----+-----+-----+ Precedencia 111 110 101 100 011 010 001 000 Control de Red Control Entre Redes CRITICO/ECP Muy urgente (Flash Override) Urgente (Flash) Inmediato Prioridad Rutina
El uso de las indicaciones de Retraso, Rendimiento y fiabilidad puede incrementar el coste (en cierto sentido) del servicio. En muchas redes un mejor rendimiento para uno de estos parmetros conlleva un peor rendimiento en algn otro. El tipo de servicio se usa para especificar el tratamiento del datagrama durante su transmisin a travs del sistema internet. Longitud Total: 16 bits. La Longitud Total es la longitud del datagrama, medida en octetos, incluyendo la cabecera y los datos. Este campo permite que la longitud mxima de un datagrama sea de 65,535 octetos. Los datagramas de tal longitud no son prcticos para la mayora de hosts y redes. Todos los hosts deben estar preparados para aceptar datagramas de hasta 576 octetos (tanto si llegan completos como en fragmentos). Se recomienda que los hosts enven datagramas mayores de 576 octetos slo si tienen la seguridad de que el destinatario est preparado para aceptarlos. El nmero 576 se ha seleccionado para permitir que un bloque de datos de tamao razonable sea transmitido junto a la informacin de cabecera necesaria. Por ejemplo, este tamao permite que un bloque de datos de 512 octetos ms 64 octetos de cabecera quepa en un datagrama . La cabecera internet de tamao mximo son 60 octetos, y una cabecera internet tpica son 20 octetos, admitiendo as un margen para cabeceras de protocolos de nivel superior. Identificacin: 16 bits. Es un valor de identificacin asignado por el remitente como ayuda en el ensamblaje de fragmentos de un datagrama. Flags (indicadores):3 bits. Son diversos indicadores de control. Bit 0: reservado, debe ser cero. Bit 1: (DF) No Fragmentar (Don't Fragment) 0 = puede fragmentarse, 1 = No Fragmentar. Bit 2: (MF) Ms Fragmentos (More Fragments) 0 = ltimo Fragmento, 1 = Ms Fragmentos. 0 1 2 +---+---+---+ | | D | M | | 0 | F | F | +---+---+---+
Posicin del Fragmento:
13 bits
Este campo indica a que parte del datagrama pertenece este fragmento.
J. Postel 14] RFC 791 1981 Protocolo Internet
[Pg. Septiembre
La posicin del fragmento se mide en unidades de 8 octetos (64 bits). El primer fragmento tiene posicin 0. Tiempo de Vida: 8 bits
Este campo indica el tiempo mximo que el datagrama tiene permitido permanecer en el sistema internet. Si este campo contiene el valor cero, entonces el datagrama debe ser destrudo. Este campo es modificado durante el procesamiento de la cabecera internet. El tiempo es medido en segundos, pero como todo mdulo que procese un datagrama debe decrementar el TTL (Time To Live: Tiempo de Vida) al menos en uno, incluso si procesa el datagrama en menos de un segundo, se debe pensar en el TTL slo como un lmite superior del tiempo durante el cual un datagrama puede existir. La intencin es hacer que los datagramas imposibles de entregar sean descartados, y limitar el mximo periodo de vida de un datagrama. Protocolo: 8 bits
Este campo indica el protocolo del siguiente nivel usado en la parte de datos del datagrama internet. Los valores de varios protocolos son especificados en "Nmeros Asignados" [9]. Suma de Control de Cabecera: de la cabecera cambian (p. ej. el tiempo de vida), esta suma es recalculada y verificada en cada punto donde la cabecera internet es procesada. El algoritmo de la suma de control es: El campo suma de control es el complemento a uno de 16 bits de la suma de los complementos a uno de todas las palabras de 16 bits de la cabecera. A la hora de calcular la suma de control, el valor inicial de este campo es cero. Esta es una suma de control fcil de calcular y la evidencia 16 bits
Suma de Control de la cabecera solamente. Dado que algunos campos
experimental indica que es adecuada, pero es provisional y puede ser reemplazada por un procedimiento CRC, dependiendo de la experiencia ulterior. Direccin de Origen: 32 bits Ver seccin 3.2.
La direccin de origen. Direccin de Destino:
32 bits
[Pg. Septiembre
La direccin de destino. Opciones: variable
Ver seccin 3.2.
Las opciones pueden o no aparecer en los datagramas. Deben ser implementadas por todos los mdulos IP (host y pasarelas). Lo que es opcional es su transmisin en cualquier datagrama en particular, no su implementacin. En algunos entornos la opcin de seguridad puede ser requerida en todos los datagramas. El campo opcin es de longitud variable. Pueden existir cero o ms opciones. Existen dos casos para el formato de una opcin: Caso 1: Caso 2: Un slo octeto de tipo-opcin. Un octeto tipo-opcin, un octeto longitud-opcin y los octetos correspondientes a los datos de opcin.
El octeto longitud-opcin es la cuenta del octeto tipo-opcin y el octeto longitud-opcin as como los octetos de datos de opcin. El octeto tipo-opcin tiene 3 campos 1 bit 2 bits 5 bits indicador de copiado, clase de opcin, nmero de opcin.
El indicador de copiado indica si esta opcin es copiada en todos los fragmentos al fragmentar. 0 = no copiada 1 = copiada Las clases de opcin son:
0 1 2 3
= = = =
control reservado para uso futuro depuracin y medida reservado para uso futuro
Se definen las siguientes opciones de internet: CLASE NUMERO LONGITUD DESCRIPCION ----- ------ -------- ----------0 0 Fin de la lista de opciones. Esta opcin ocupa un slo octeto. No tiene octeto de
[Pg. Septiembre
0 slo 0 Restricciones 0 encaminar
1 2
11
longitud. Sin Operacin. Esta opcin ocupa un octeto. No tiene octeto de longitud. Seguridad. Usado para Seguridad, Compartimentacin, Grupo de Usuario (TCC), y Cdigos de Manejo de compatibles con los requerimientos del Departamento de Defensa. Encaminamiento de Origen No Estricto (Loose Source Routing). Usado para el datagrama internet en base a la informacin suministrada por el
var.
origen. 0 el datagrama internet en base a la informacin 0 para rastrear la ruta que sigue un datagrama 0 Usado para transportar el identificador de flujo. 2 4 var. Marca de Tiempo Internet (Internet Timestamp) 8 4 internet. Identificador de Flujo (Stream ID). 7 var. suministrada por el origen. Registrar Ruta (Record Route). Usado 9 var. Encaminamiento de Origen Fijo (Strict Source Routing). Usado para encaminar
Definiciones de Opciones Especficas Fin De La Lista de Opciones
+--------+ |00000000| +--------+ Tipo=0 Esta opcin indica el final de la lista de opciones. Esta puede no coincidir con el final de la cabecera internet sgn expresa la longitud de cabecera internet. Se usa al final de todas las opciones, no al final de cada opcin, y slo es necesario usarla si, caso de no hacerlo, el final de las opciones no coincidiera con el final de la cabecera internet. Puede ser copiado, introducido o borrado en la fragmentacin, o por cualquier otra razn.
J. Postel 17] RFC 791 1981 Sin Operacin +--------+ |00000001| +--------+ Tipo=1 Protocolo Internet
[Pg. Septiembre
Esta opcin puede usarse entre opciones para, por ejemplo, ajustar el comienzo de una opcin siguiente a una posicin mltiplo de 32 bits. Puede ser copiado, introducido o borrado en la fragmentacin, o por cualquier otra razn. Seguridad Esta opcin proporciona a los hosts una forma de enviar parmetros de seguridad, compartimentacin, manejo de restricciones y TCC (grupo de usuarios cerrado). El formato de esta opcin es el siguiente: +--------+--------+---//---+---//---+---//---+---//---+ |10000010|00001011|SSS SSS|CCC CCC|HHH HHH| TCC | +--------+--------+---//---+---//---+---//---+---//---+ Tipo=130 Longitud=11
Seguridad (campo S):
16 bits
Especifica uno de entre 16 niveles de seguridad (ocho de los cuales estn reservados para uso futuro) 00000000 11110001 01111000 10111100 01011110 10101111 11010111 01101011 00110101 10011010 01001101 00100100 00010011 10001001 11000100 11100010 00000000 00110101 10011010 01001101 00100110 00010011 10001000 11000101 11100010 11110001 01111000 10111101 01011110 10101111 11010110 01101011 No Clasificado Confidencial EFTO MMMM PROG Restringido Secreto Alto Secreto (Reservado para (Reservado para (Reservado para (Reservado para (Reservado para (Reservado para (Reservado para (Reservado para
uso uso uso uso uso uso uso uso
futuro) futuro) futuro) futuro) futuro) futuro) futuro) futuro)
[Pg. Septiembre
Compartimentos (Campo C): valor
16 bits
Cuando la informacin no est compartimentada se usa un de todo ceros. Otros valores para el campo Compartimentos pueden obtenerse de la Agencia de Inteligencia de Defensa. Manejo de Restricciones (campo H): 16 bits Los valores para los marcadores de control y liberacin son digrafos alfanumricos y estn definidos en el Manual DIAM 65-19 "Marcadores de Seguridad Estndar", de la Agencia de Inteligencia de Defensa. Cdigo de Control de Transmisin (Campo TCC): 24 bits Proporciona un mecanismo para segregar el trfico y definir comunidades de inters controladas entre diversos suscriptores. Los valores TCC son trigrafos, se pueden encontrar en "HQ DCA Code 530". Debe copiarse al fragmentar. Esta opcin aparece como mximo una vez en un datagrama. Ruta de Origen No Estricta y Registrar Ruta +--------+--------+--------+---------//--------+
|10000011| long. | puntero| datos de ruta | +--------+--------+--------+---------//--------+ Tipo=131 La opcin de Encaminamiento de Origen No Estricto y Registrar Ruta ("loose source and record route (LSRR)") proporciona un mecanismo mediante el cual el origen de un datagrama internet puede suministrar informacin de encaminamiento que ser usada por las pasarelas para transmitir el datagrama a su destino, y para almacenar la informacin de la ruta. La opcin comienza con el cdigo de tipo de opcin. El segundo octeto es la longitud de la opcin que incluye al cdigo de tipo de opcin, al propio octeto de longitud, al octeto con el puntero y a los (long. - 3) octetos de datos de la ruta. El tercer octeto es el puntero a los datos de ruta que indica el octeto en el cual comienza la siguiente direccin de origen a procesar. El puntero es relativo a esta opcin, y el valor legal ms pequeo para el puntero es 4. Los datos de ruta se componen de una serie de direcciones internet. Cada direccin internet son 32 bits o 4 octetos. Si el
[Pg. Septiembre
puntero es mayor que la longitud, la ruta de origen est vaca (y la ruta registrada llena) y el encaminamiento debe basarse en el campo de la direccin de destino. Si se ha alcanzado la direccin indicada en el campo direccin de destino y el puntero no es mayor que la longitud, la siguiente direccin en la ruta de origen sustituye a la direccin del campo de direccin de destino, y la direccin de ruta registrada sustituye a la direccin de origen recin usada, y se suma cuatro al puntero. La direccin de ruta registrada es la propia direccin internet que tiene el mdulo internet en el entorno en el cual el datagrama est siendo reenviado. Este procedimiento de sustituir la ruta de origen con la ruta registrada (si bien est en orden inverso del necesario para ser usada como ruta de origen) significa que la opcin (y la cabecera IP en su totalidad) sigue teniendo una longitud constante a medida que el datagrama progresa a travs de internet.
Esta opcin es una ruta de origen no estricta porque la pasarela o IP del host puede utilizar cualquier ruta con cualquier nmero de pasarelas intermedias para alcanzar la siguiente direccin en la ruta. Debe copiarse al fragmentar. Aparece como mximo una vez en un datagrama. Ruta de Origen Estricta y Registrar Ruta +--------+--------+--------+---------//--------+ |10001001| long. | puntero| datos de ruta | +--------+--------+--------+---------//--------+ Tipo=137 La opcin de Ruta de Origen Estricta y Registrar Ruta (strict source and record route (SSRR)) proporciona al origen de un datagrama internet un medio de suministrar informacin de encaminamiento a ser usada por las pasarelas al reenviar el datagrama al destino y para registrar la informacin de la ruta. La opcin comienza con el cdigo de tipo de opcin. El segundo octeto es la longitud de la opcin que incluye al cdigo de tipo de opcin, al propio octeto de longitud, al octeto con el puntero y a los (long. - 3) octetos de datos de la ruta. El tercer octeto es el puntero a los datos de ruta que indica el
[Pg. Septiembre
octeto en el cual comienza la siguiente direccin de origen a procesar. El puntero es relativo a esta opcin, y su menor valor legal es 4. Los datos de ruta se componen de una serie de direcciones internet. Cada direccin internet son 32 bits o 4 octetos. Si el puntero es mayor que la longitud, la ruta de origen est vaca (y la ruta registrada llena) y el encaminamiento debe basarse en el campo de la direccin de destino. Si se ha alcanzado la direccin indicada en el campo de direccin de destino y el puntero no es mayor que la longitud, la siguiente direccin en la ruta de origen sustituye a la direccin del campo de direccin de destino, y la direccin de ruta registrada sustituye a la direccin de origen recin usada, y se suma cuatro al puntero.
La direccin de ruta registrada es la propia direccin internet del mdulo internet tal y como es en el entorno en el cual el datagrama est siendo reexpedido. Este procedimiento de sustituir la ruta de origen con la ruta registrada (si bien est en orden inverso del necesario para ser usada como ruta de origen) significa que la opcin (y la cabecera IP en su totalidad) sigue teniendo una longitud constante a medida que el datagrama progresa a travs de internet. Esta opcin es una ruta de origen estricta porque la pasarela o el IP del host deben enviar el datagrama directamente a la siguiente direccin en la ruta de origen slamente a travs de la red conectada directamente indicada en la siguiente direccin, para alcanzar la siguiente pasarela o host especificado en la ruta. Debe copiarse al fragmentar. Aparece como mximo una vez en un datagrama. Registrar Ruta +--------+--------+--------+---------//--------+ |00000111| long. | puntero| datos de ruta | +--------+--------+--------+---------//--------+ Tipo=7 La opcin de Registrar Ruta proporciona un mecanismo para registrar la ruta de un datagrama internet.
[Pg. Septiembre
La opcin comienza con el cdigo de tipo de opcin. El segundo octeto es la longitud de la opcin que incluye al cdigo de tipo de opcin, al propio octeto de longitud, al octeto con el puntero y a los (long. - 3) octetos de datos de la ruta.El tercer octeto es el puntero a los datos de ruta que indica el octeto en el cual comienza la siguiente area para almacenar una direccin de ruta. El puntero es relativo a esta opcin, y su menor valor legal es 4. Una ruta registrada se compone de una serie de direcciones internet. Cada direccin internet son 32 bits o 4 octetos. Si el puntero es mayor que la longitud, el area de datos de la ruta registrada esta llena. El host de origen debe construir esta
opcin con una rea de datos de ruta con suficiente espacio para contener todas las direcciones esperadas. El tamao de la opcin no cambia al agregar direcciones. El contenido inicial del rea de datos de ruta debe ser cero. Cuando un mdulo internet encamina un datagrama, comprueba si la opcin Registrar ruta est presente. Si lo est, inserta su propia direccin internet, tal y como se la conoce en el entorno en el cual el datagrama est siendo transmitido, en la ruta registrada, comenzando en el octeto indicado por el puntero, e incrementa el puntero en cuatro. Si el rea de datos de ruta ya est llena (el puntero sobrepasa a longitud) el datagrama es transmitido sin insertar la direccin en la ruta registrada. Si hay algo de espacio pero no el suficiente para insertar una direccin completa, el datagrama original es considerado errneo y descartado. En ambos casos se puede enviar un mensaje de problema de parmetros ICMP al host de origen [3]. No se copia al fragmentar, va slo en el primer fragmento. Aparece como mximo una vez en un datagrama. Identificador de Flujo +--------+--------+--------+--------+ |10001000|00000010| ID de Flujo | +--------+--------+--------+--------+ Tipo=136 Longitud=4 Esta opcin proporciona una forma de transportar el identificador de flujo SATNET de 16 bits a travs de redes que no soportan el concepto de flujo. Debe copiarse al fragmentar. Aparece como mximo una vez en un
J. Postel 22] RFC 791 1981 datagrama. Marca de tiempo Internet +--------+--------+--------+--------+ |01000100| long. | puntero|oflw|flg| +--------+--------+--------+--------+ Protocolo Internet
[Pg. Septiembre
| direccin internet | +--------+--------+--------+--------+ | Marca de tiempo | +--------+--------+--------+--------+ | . | . . Tipo = 68 La Longitud de opcin es el nmero de octetos en la opcin contando los octetos de tipo, longitud, puntero y desbordamiento/indicadores (oflw/flg, overflow/flags) (mxima longitud: 40) El puntero es el nmero de octetos desde el principio de esta opcin hasta el final de las marcas de tiempo mas uno (es decir, apunta al octeto de comienzo del espacio para la siguiente marca de tiempo). El valor legal mnimo es 5. El rea de marca de tiempo est llena cuando el puntero es mayor que la longitud. El Desbordamiento (oflw) (4 bits) es el nmero de mdulos IP que no han podido registrar marcas de tiempo debido a falta de espacio. Los valores de los Indicadores (4 bits) son 0 -- Slo marcas de tiempo, almacenadas en palabras de 32 bits consecutivas, 1 -- cada marca de tiempo es precedida con la direccin internet de la entidad registradora, 3 -- Los campos de direccin internet estn preespecificados. Un mdulo IP registra su marca de tiempo slo si su direccin concuerda con la siguiente direccin internet especificada. La Marca de Tiempo es una marca temporal de 32 bits, justificada a la derecha, en milisegundos desde la medianoche UT. Si el tiempo no est disponible en milisegundos o no puede darse con respecto a la medianoche UT, entonces se puede insertar
[Pg. Septiembre
cualquier tiempo como marca de tiempo, siempre que el bit de mayor orden sea puesto a uno para indicar el uso de un valor no estndar.
El host de origen debe construir est opcin con un rea de datos para la marca de tiempo lo sufucientemente grande para que quepa toda la informacin de marcas temporales esperada. El tamao de la opcin no cambia al aadir marcas de tiempo. El contenido inicial del rea de datos de marcas de tiempo debe ser cero o pares direccin internet/cero. Si el rea de datos de marca de tiempo ya est llena (el puntero sobrepasa a la longitud) el datagrama es transmitido sin insertar marca de tiempo, pero el contador de desbordamiento es incrementado en uno. Si hay algo de espacio pero no el suficiente para insertar una marca de tiempo completa, o el contador de desbordamiento el mismo se desborda, el datagrama original es considerado errneo y descartado. En ambos casos se puede enviar un mensaje de problema de parmetros ICMP al host de origen [3]. La opcin de marca de tiempo no se copia al fragmentar. Es transportada slo en el primer fragmento. Aparece como mximo una vez en un datagrama. Valor de Relleno: variable El Valor de Relleno se usa para asegurar que la cabecera internet ocupa un multiplo de 32 bits. El valor de relleno es cero.
Cabecera IP
Saltar a: navegacin, bsqueda
Contenido

1 Formato de la cabecera IP 2 Descripcin de cada uno de los campos o 2.1 Versin: 4 bits o 2.2 Tamao Cabecera (IHL): 4 bits o 2.3 Tipo de Servicio: 8 bits o 2.4 Longitud Total: 16 bits o 2.5 Identificador: 16 bits o 2.6 Flags: 3 bits o 2.7 Posicin de Fragmento: 13 bits o 2.8 Tiempo de Vida (TTL): 8 bits o 2.9 Protocolo: 8 bits o 2.10 Suma de Control de Cabecera: 16 bits o 2.11 Direccin IP de origen: 32 bits o 2.12 Direccin IP de destino: 32 bits o 2.13 Opciones: Variable 2.13.1 Formato de opciones simple 2.13.2 Formato de opciones compuesto o 2.14 Relleno: Variable 3 Vase tambin
Formato de la cabecera IP
Formato de la Cabecera IP (Versin 4) 0-3 Versin 4-7 Tamao Cabecera 8-15 Tipo de Servicio 16-18 19-31 Longitud Total
Identificador
Flags
Posicin de Fragmento
Time To Live
Protocolo
Suma de Control de Cabecera
Direccin IP de Origen
Direccin IP de Destino
Opciones
Relleno
Descripcin de cada uno de los campos
Versin: 4 bits
Siempre vale lo mismo (0100). Este campo describe el formato de la cabecera utilizada. En la tabla se describe la versin 4.
Tamao Cabecera (IHL): 4 bits
Longitud de la cabecera, en palabras de 32 bits. Su valor mnimo es de 5 para una cabecera correcta, y el mximo de 15.
Tipo de Servicio: 8 bits
Indica una serie de parmetros sobre la calidad de servicio deseada durante el trnsito por una red. Algunas redes ofrecen prioridades de servicios, considerando determinado tipo de paquetes "ms importantes" que otros (en particular estas redes solo admiten los paquetes con prioridad alta en momentos de sobrecarga). Estos 8 bits se agrupan de la siguiente manera. Los 5 bits de menos peso son independientes e indican caractersticas del servicio:
Bit 0: sin uso, debe permanecer en 0. Bit 1: 1 costo mnimo, 0 costo normal. Bit 2: 1 mxima fiabilidad, 0 fiabilidad normal. Bit 3: 1 mximo rendimiento, 0 rendimiento normal. Bit 4: 1 mnimo retardo, 0 retardo normal.
Los 3 bits restantes estn relacionados con la precedencia de los mensajes, un indicador adjunto que indica el nivel de urgencia basado en el sistema militar de precedencia (vase Message Precedence) de la CCEB, un organizacin de comunicaciones electrnicas militares formada por 5 naciones. La urgencia que estos estados representan aumenta a medida que el nmero formado por estos 3 bits lo hace, y responden a los siguientes nombres.
000: De rutina. 001: Prioritario. 010: Inmediato. 011: Relmpago. 100: Invalidacin relmpago. 101: Procesando llamada crtica y de emergencia. 110: Control de trabajo de Internet. 111: Control de red.
Longitud Total: 16 bits
Es el tamao total, en octetos, del datagrama, incluyendo el tamao de la cabecera y el de los datos. El tamao mnimo de los datagramas usados normalmente es de 576 octetos (64 de cabeceras y 512 de datos). Una mquina no debera enviar datagramas menores o mayores de ese tamao a no ser que tenga la certeza de que van a ser aceptados por la mquina destino. En caso de fragmentacin este campo contendr el tamao del fragmento, no el del datagrama original.
Identificador: 16 bits
Identificador nico del datagrama. Se utilizar, en caso de que el datagrama deba ser fragmentado, para poder distinguir los fragmentos de un datagrama de los de otro. El originador del datagrama debe asegurar un valor nico para la pareja origen-destino y el tipo de protocolo durante el tiempo que el datagrama pueda estar activo en la red. El valor asignado en este campo debe ir en formato de red.
Flags: 3 bits
Actualmente utilizado slo para especificar valores relativos a la fragmentacin de paquetes:

bit 2: Reservado; debe ser 0 bit 1: 0 = Divisible, 1 = No Divisible (DF) bit 0: 0 = ltimo Fragmento, 1 = Fragmento Intermedio (le siguen ms fragmentos) (MF) La indicacin de que un paquete es indivisible debe ser tenida en cuenta bajo cualquier circunstancia. Si el paquete necesitara ser fragmentado, no se enviar. Posicin de Fragmento: 13 bits
En paquetes fragmentados indica la posicin, en unidades de 64 bits, que ocupa el paquete actual dentro del datagrama original. El primer paquete de una serie de fragmentos contendr en este campo el valor 0.
Tiempo de Vida (TTL): 8 bits
Indica el mximo nmero de enrutadores que un paquete puede atravesar. Cada vez que algn nodo procesa este paquete disminuye su valor en 1 como mnimo, una unidad. Cuando llegue a ser 0, el paquete ser descartado.
Protocolo: 8 bits
Indica el protocolo de las capas superiores al que debe entregarse el paquete Vea Nmeros de protocolo IP para comprender como interpretar este campo.
Suma de Control de Cabecera: 16 bits Suma de Contol de cabecera. Se recalcula cada vez que algn nodo cambia alguno de sus campos (por ejemplo, el Tiempo de Vida). El mtodo de clculo intencionadamente simple- consiste en sumar en complemento a 1 cada palabra de 16 bits de la cabecera (considerando valor 0 para el campo de suma de control de cabecera) y hacer el complemento a 1 del valor resultante. Direccin IP de origen: 32 bits Ver Direcciones IP. Debe ser dada en formato de red. Direccin IP de destino: 32 bits Ver Direcciones IP. Debe ser dada en formato de red. Opciones: Variable
Aunque no es obligatoria la utilizacin de este campo, cualquier nodo debe ser capaz de interpretarlo. Puede contener un nmero indeterminado de opciones, que tendrn dos posibles formatos:
Formato de opciones simple
Se determina con un slo octeto indicando el Tipo de opcin, el cual est dividido en 3 campos.
Indicador de copia: 1 bit. En caso de fragmentacin, la opcin se copiar o no a cada nuevo fragmento segn el valor de este campo: 0 = no se copia 1 = se copia.
Clase de opcin: 2 bits. Las posibles clases son: 0 = control 1 = reservada 2 = depuracin y mediciones 3 = ya esta.
Nmero de opcin: 5 bits. Identificador de la opcin.
Formato de opciones compuesto
Un octeto para el Tipo de opcin, otro para el Tamao de opcin, y uno o ms octetos conformando los Datos de opcin. El Tamao de opcin incluye el octeto de Tipo de opcin, el de Tamao de opcin y la suma de los octetos de datos. La siguiente tabla muestra las opciones actualmente definidas:
Clase Nmero Tamao 0 0 0 0 0 0 0 2 0 1 2 3 9 7 8 4 11
Descripcin Final de lista de opciones. Formato simple. Ninguna operacin (NOP). Formato simple. Seguridad.
variable Enrutado desde el Origen, abierto (Loose Source Routing). variable Enrutado desde el Origen, estricto (Strict Source Routing). variable Registro de Ruta (Record Route). 4 Identificador de flujo (Stream ID).
variable Marca de tiempo (Internet Timestamping).
Final de Lista de Opciones: Se usa al final de la lista de opciones, si sta no coincide con el final de la cabecera IP. Ninguna Operacin (NOP): Se puede usar para forzar la alineacin de las opciones en palabras de 32 bits. Seguridad: Especifica niveles de seguridad que van desde "No Clasificado" hasta "Mximo Secreto", definidos por la Agencia de Seguridad de la Defensa (de EE.UU.). Enrutado desde el Origen (abierto) y Registro de Ruta (LSSR): Esta opcin provee el mecanismo para que el originador de un datagrama pueda indicar el itinerario que ha de seguir a travs de la red y para registrar el camino seguido. Los Datos de Opcin consisten en un puntero (un octeto) y una lista de direcciones IP (4 octetos cada una) que se han de alcanzar ("procesar"): El puntero indica la posicin de la siguiente direccin de la ruta, dentro de la Opcin; as, su valor mnimo es de 4. Cuando un nodo de Internet procesa la direccin de la lista apuntada por el puntero (es decir, se alcanza esa direccin) incrementa el puntero en 4, y redirige el paquete a la siguiente direccin. Si el puntero llega a ser mayor que el Tamao de Opcin significa que la informacin de ruta se ha procesado y registrado completamente y se redirigir el paquete a su direccin de destino.
Si se alcanza la direccin de destino antes de haber procesado la lista de direcciones completa (el puntero es menor que el Tamao de Opcin) la siguiente direccin de la lista reemplaza a la direccin de destino del paquete y es a su vez reeemplazada por la direccin del nodo que est procesando el datagrama ("Ruta Registrada"), incrementando, adems, el puntero en 4. Utilizando este mtodo de sustituir la direccin especificada en origen por la Ruta Registrada se asegura que el tamao de la Opcin (y de la cabecera IP) no vara durante su recorrido por la red. Se considera que la ruta especificada por el originador es "abierta" porque cualquier nodo que procesa el paquete es libre de dirigirlo a la siguiente direccin siguiendo cualquier otra ruta intermedia. Slo puede usarse una vez en un datagrama, y, en caso de fragmentacin, la opcin se copiar a los paquetes resultantes. Enrutado desde el Origen (estricto) y Registro de Ruta (SSRR): Exactamente igual que LSSR, excepto en el tratamiento que los nodos harn de este datagrama. Al ser la ruta especificada "estricta", un nodo debe reenviar el paquete directamente a la siguiente direccin, es decir, no podr redireccionarlo por otra red. Registro de Ruta: Mediante el uso de esta Opcin se puede registrar el itinerario de un datagrama. Los Datos de Opcin consisten en un puntero (un octeto) y un espacio relleno de ceros que contendr la Ruta Registrada para el paquete. Cuando un nodo recibe un paquete en el que est presente esta opcin, escribir su direccin IP en la posicin indicada por el puntero, siempre que sta sea menor que el Tamao de Opcin, e incrementar el puntero en 4. Es preciso que el espacio reservado para la Ruta Registrada tenga una longitud mltiplo de 4; si al intentar grabar su direccin un nodo detecta que existe espacio libre pero es menor de 4 octetos, el paquete no se reenva (se pierde) y se notifica el error, mediante ICMP, al originador del datagrama. Esta Opcin no se copia en caso de fragmentacin, y slo puede aparecer una vez en un paquete. Relleno: Variable
Utilizado para asegurar que el tamao, en bits, de la cabecera es un mltiplo de 32. El valor usado es el 0.
IPV6
3.
Formato de la Cabecera IPv6 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Versin|Clase d Trfico| Etiqueta de Flujo | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Longitud de la Carga til |Cabcera Siguien|Lmite d Saltos| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Direccin Origen + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Direccin Destino + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Versin Clase de Trfico Etiqueta de Flujo Nmero = 6 de versin del Protocolo Internet de 4 bits. Campo clase de trfico de 8 bits. Ver la seccin 7. Etiqueta de flujo de 20 bits. Ver la seccin 6. Track de Estndares Especificacin del IPv6 [Pgina Diciembre
Deering & Hinden 4] RFC 2460 1998
Longitud de la Carga til del
Entero sin signo de 16 bits. Longitud de la carga til IPv6, es decir, el resto paquete que sigue a esta cabecera IPv6,
en octetos. (Notar que cualesquiera de las cabeceras de extensin [seccin 4] presente es considerada parte de la carga til, es decir, incluida en el conteo de la longitud).
Cabecera Siguiente de
Selector de 8 bits. Identifica el tipo cabecera que sigue inmediatamente a la cabecera IPv6. Utiliza los mismos
valores que el campo Protocolo del IPv4 [RFC1700 et seq.]. Lmite de Saltos paquete. Se descarta el paquete si el Lmite de Saltos es decrementado hasta cero. Direccin Origen Direccin Destino el ltimo recipiente, si est presente una cabecera Enrutamiento). Ver la [ADDRARCH] y la seccin 4.4. Direccin de 128 bits del originador del paquete. Ver la [ADDRARCH]. Direccin de 128 bits del recipiente pretendido del paquete (posiblemente no Entero sin signo de 8 bits. Decrementado en 1 por cada nodo que reenva el
Track de Estndares Especificacin del IPv6
[Pgina Diciembre
4. Cabeceras de Extensin IPv6 En el IPv6, la informacin de capa internet opcional se codifica en cabeceras separadas que se pueden colocar entre la cabecera IPv6 y la cabecera de capa superior dentro de un paquete. Hay un nmero pequeo de tales cabeceras de extensin, cada una identificada por
un valor de Cabecera Siguiente distinto. Segn lo ilustrado en estos ejemplos, un paquete IPv6 puede llevar cero, una, o ms cabeceras de extensin, cada una identificada por el campo Cabecera Siguiente de la cabecera precedente: +---------------+-----------------------| Cabecera IPv6 | Cabecera TCP + datos | | |Cabcera Sig. = | | TCP | +---------------+-----------------------+---------------+----------------+-----------------------| Cabecera IPv6 |Cabcera Enrutam.| Cabecera TCP + datos | | | |Cabcera Sig. = |Cabecera Sig. = | | Enrutamiento | TCP | +---------------+----------------+-----------------------+---------------+----------------+-----------------+---------------| Cabecera IPv6 |Cabcera Enrutam.|Cabcera Fragmento|fragmento de Cab. | | | | TCP + datos |Cabcera Sig. = |Cabecera Sig. = |Cabecera Sig. = | | Enrutamiento | Fragmento | TCP | +---------------+----------------+-----------------+---------------Con una excepcin, las cabeceras de extensin no son examinadas ni procesadas por ningn nodo a lo largo de la ruta de entrega de un paquete, hasta que el paquete alcance el nodo (o cada uno del conjunto de nodos, en el caso de multienvo) identificado en el campo Direccin Destino de la cabecera IPv6. All, el demultiplexaje normal en el campo Cabecera Siguiente de la cabecera IPv6 invoca el mdulo para procesar la primera cabecera de extensin, o la cabecera de capa superior si no hay ninguna cabecera de extensin presente. El contenido y la semntica de cada cabecera de extensin determinan si se procede o no a la cabecera siguiente. Por lo tanto, las cabeceras de extensin se deben procesar estrictamente en el orden que aparecen en el paquete; un receptor no debe, por ejemplo, examinar a travs de un paquete buscando un tipo en particular de cabecera de extensin y procesar esa cabecera antes de procesar todas las precedentes.
Deering & Hinden 6]
Track de Estndares
[Pgina
RFC 2460 1998
Especificacin del IPv6
Diciembre
La excepcin mencionada en el prrafo precedente es la cabecera Opciones de Salto a Salto, la cual lleva informacin que debe ser examinada y procesada por cada nodo a lo largo de la ruta de entrega de un paquete, incluyendo los nodos de origen y de destino. La cabecera Opciones de Salto a Salto, cuando est presente, debe seguir inmediatamente a la cabecera IPv6. Su presencia es indicada por el valor cero en el campo Cabecera Siguiente de la cabecera IPv6. Si, como resultado de procesar una cabecera, un nodo necesita proceder a la cabecera siguiente pero el valor Cabecera Siguiente en la cabecera actual es desconocido por el nodo, debe descartar el paquete y enviar un mensaje ICMP de Problema de Parmetro al origen del paquete, con un valor Cdigo ICMP de 1 ("encontrado tipo de Cabecera Siguiente desconocido") y el campo Puntero ICMP conteniendo el desplazamiento del valor desconocido dentro del paquete original. La misma accin se debera tomar si un nodo encuentra un valor Cabecera Siguiente de cero en cualquier cabecera con excepcin de una cabecera IPv6. Cada cabecera de extensin es un entero mltiplo de 8 octetos de largo, para conservar la alineacin de 8 octetos para las cabeceras subsiguientes. Los campos Multiocteto dentro de cada cabecera de extensin se alinean en sus lmites naturales, es decir, los campos de ancho de n octetos son colocados en un entero mltiplo de n octetos desde el inicio de la cabecera, para n = 1, 2, 4, o 8. Una implementacin completa del IPv6 comprende la implementacin de las siguientes cabeceras de extensin: Opciones de Salto a Salto Enrutamiento (Tipo 0) Fragmento Opciones de Destino Autenticacin Seguridad del Encapsulado de la Carga til Las primeras cuatro estn especificadas en este documento; las ltimas dos estn especificadas en la [RFC-2402] y la [RFC-2406], respectivamente. 4.1 Orden de las Cabeceras de Extensin Cuando ms de una cabecera de extensin se usa en un mismo paquete, se recomienda que esas cabeceras aparezcan en el siguiente orden: Cabecera Cabecera Cabecera Cabecera Cabecera IPv6 Opciones de Salto a Salto Opciones de Destino (nota 1) Enrutamiento Fragmento
[Pgina Diciembre
Cabecera Autenticacin (nota 2) Cabecera Seguridad del Encapsulado de la Carga til (nota 2) Cabecera Opciones de Destino (nota 3) Cabecera de Capa Superior nota 1: para las opciones a ser procesadas por el primer destino que aparece en el campo Direccin Destino IPv6 ms los destinos subsiguientes listados en la Cabecera Enrutamiento. nota 2: recomendaciones adicionales con respecto al orden relativo de las cabeceras Autenticacin y Seguridad del Encapsulado de la Carga til se dan en la [RFC-2406]. nota 3: para las opciones a ser procesadas solo por el destino final del paquete. Cada cabecera de extensin debe ocurrir solamente una vez, a excepcin de la cabecera Opciones de Destino la cual debe de ocurrir a lo sumo dos veces (una vez antes de una cabecera Enrutamiento y la otra vez antes de una cabecera de capa superior). Si la cabecera de capa superior es otra cabecera IPv6 (en el caso de que el IPv6 sea tunelizado o encapsulado en el IPv6), puede ser seguida por sus propias cabeceras de extensin, las cuales estn separadamente sujetas a las mismas recomendaciones de orden. Siempre y cuando se definan otras cabeceras de extensin, sus restricciones de orden concerniente a las cabeceras arriba listadas deben ser especificadas. Los nodos IPv6 deben aceptar e intentar procesar cabeceras de extensin en cualquier orden y cualquier nmero de veces que ocurran en un mismo paquete, a excepcin de la cabecera Opciones de Salto a Salto la cual est restringida a aparecer slo inmediatamente despus de una cabecera IPv6. No obstante, se aconseja fuertemente que los originadores de paquetes IPv6 se apeguen al orden recomendado arriba hasta y a menos que especificaciones subsiguientes corrijan esa recomendacin.
Deering & Hinden 8] RFC 2460 1998 4.2 Opciones
[Pgina Diciembre
Dos de las cabeceras de extensin actualmente definidas -- la cabecera Opciones de Salto a Salto y la cabecera Opciones de Destino -- llevan un nmero variable de "opciones" codificadas tipolongitudvalor (TLV), de la siguiente forma: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - |Tipo de Opcin | Lon Datos Opc |Datos d la Opcin +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - Tipo de Opcin Lon Datos Opc Identificador de 8 bits del tipo de opcin. Entero sin signo de 8 bits. Longitud del campo Datos de la Opcin de esta opcin, en octetos. Campo de longitud variable. Datos del Tipo de Opcin. La secuencia de opciones dentro de una cabecera se deben procesar estrictamente en el orden que aparecen en la cabecera; un receptor no debe, por ejemplo, examinar a travs de una cabecera buscando un tipo en particular de opcin y procesar esa opcin antes de procesar todas las precedentes. Los identificadores Tipo de Opcin se codifican internamente tales que sus 2 bits de ms alto orden especifican la accin que se debe tomar si el nodo IPv6 en proceso no reconoce el Tipo de Opcin: 00 - no tomar en cuenta esta opcin y continuar procesando la cabecera. 01 - descartar el paquete. 10 - descartar el paquete y, sin tener en cuenta si o no la Direccin Destino del paquete fue una direccin multienvo, enviar un mensaje ICMP Problema de Parmetro, Cdigo 2, a la Direccin Origen del paquete sealando el Tipo de Opcin desconocido. 11 - descartar el paquete y, solo si la Direccin Destino del paquete no fue una direccin multienvo, enviar un mensaje
Datos de la Opcin especficos
ICMP Problema de Parmetro, Cdigo 2, a la Direccin Origen del paquete sealando el Tipo de Opcin desconocido. El tercer bit de ms alto orden del Tipo de Opcin especifica si o no los Datos de la Opcin de esa opcin pueden modificar el enrutado hacia el destino final del paquete. Cuando una cabecera Autenticacin Deering & Hinden 9] RFC 2460 1998 Track de Estndares Especificacin del IPv6 [Pgina Diciembre
est presente en el paquete, para cualquier opcin cuyos datos pueden modificar el enrutado, su campo entero Datos de la Opcin se debe tratar como octetos de valor cero cuando se calcula o verifica el valor de autenticidad del paquete. 0 - los Datos de la Opcin no modifican el enrutado. 1 - los Datos de la Opcin pueden modificar el enrutado. Los tres bits de alto orden descritos arriba estn para ser tratados como parte del Tipo de Opcin, no independientemente del Tipo de Opcin. Es decir, una opcin en particular se identifica por un Tipo de Opcin de 8 bits completo, no slo por los 5 bits de bajo orden de un Tipo de Opcin. El mismo espacio de enumeracin del Tipo de Opcin se usa tanto para la cabecera Opciones de Salto a Salto como para la cabecera Opciones de Destino. Sin embargo, la especificacin de una opcin en particular puede restringir su uso a solamente una de esas dos cabeceras. Las opciones individuales pueden tener requisitos especficos de alineacin, para asegurar que los valores multiocteto dentro de los campos Datos de la Opcin caigan en lmites naturales. El requisito de alineacin de una opcin se especifica usando la notacin xn+y, lo que significa que el Tipo de Opcin debe aparecer en un entero mltiplo de x octetos desde el inicio de la cabecera, ms y octetos. Por ejemplo: 2n del 8n+2 del comienzo de la cabecera, ms 2 octetos. Hay dos opciones de relleno las cuales se usan cuando es necesario comienzo de la cabecera. significa cualquier desplazamiento de 8 octetos a partir significa cualquier desplazamiento de 2 octetos a partir
alinear opciones subsiguientes y rellenar la cabecera contenedora a una longitud mltiplo de 8 octetos. Estas opciones de relleno deben ser reconocidas por todas las implementaciones IPv6: Opcin Pad1 (requisito de alineacin: ninguno) +-+-+-+-+-+-+-+-+ | 0 | +-+-+-+-+-+-+-+-+ NOTA! el formato de la opcin Pad1 es un caso especial -- no tiene los campos longitud y valor. La opcin Pad1 se usa para insertar un octeto de relleno dentro del rea de Opciones de una cabecera. Si se requiere ms de un Deering & Hinden 10] RFC 2460 1998 Track de Estndares Especificacin del IPv6 [Pgina Diciembre
octeto de relleno, la opcin PadN, descrita a continuacin, se debera usar, en lugar de mltiples opciones Pad1. Opcin PadN (requisito de alineacin: ninguno) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - | 1 | Lon Datos Opc |Datos d la Opcin +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - La opcin PadN se usa para insertar dos o ms octetos de relleno dentro del rea de Opciones de una cabecera. Para N octetos de relleno, el campo Lon Datos Opc contiene el valor N-2, y el campo Datos de la Opcin consiste en N-2 octetos de valor cero. El Apndice B contiene pautas de formateo para disear Opciones nuevas. 4.3 Cabecera Opciones de Salto a Salto La cabecera Opciones de Salto a Salto se usa para llevar informacin opcional que debe ser examinada por cada nodo a lo largo de la ruta de entrega de un paquete. La cabecera Opciones de Salto a Salto se identifica por un valor Cabecera Siguiente de 0 en la cabecera IPv6, y tiene el siguiente formato: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cabcera Siguien| Lon Cab Ext | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | . . . Opciones . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cabecera Siguiente cabecera
Selector de 8 bits. Identifica el tipo de cabecera que sigue inmediatamente a la Opciones de Salto a Salto. Utiliza los mismos valores que el campo Protocolo del IPv4 [RFC1700 et seq.].
Lon Cab Ext octetos. Opciones que
Entero sin signo de 8 bits. Longitud de la cabecera Opciones de Salto a Salto en unidades de 8 octetos, no incluye los primeros 8 Campo de longitud variable, de longitud tal la cabecera Opciones de Salto a Salto completa es un entero mltiplo de 8 octetos de largo. Contiene una o ms opciones codificadas TLV, como se describe en la seccin 4.2.
[Pgina Diciembre
Las nicas opciones de salto a salto definidas en este documento son las opciones Pad1 y PadN especificadas en la seccin 4.2. 4.4 Cabecera Enrutamiento La cabecera Enrutamiento es utilizada por un origen IPv6 para listar uno o ms nodos intermedio a ser "visitados" en el camino hacia el destino de un paquete. Esta funcin es muy similar a las opciones Origen Impreciso y Registro de Ruta del IPv4. La cabecera Enrutamiento se identifica por una Cabecera Siguiente de valor 43 en la cabecera inmediatamente precedente, y tiene el siguiente formato: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cabcera Siguien| Lon Cab Ext |Tipo d Enrutami|Segmentos Dejad| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . datos especficos del tipo . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Cabecera Siguiente Selector de 8 bits. Identifica el tipo de cabecera que sigue inmediatamente a la cabecera Enrutamiento. Utiliza los mismos valores que el campo Protocolo del IPv4 [RFC-1700 et seq.]. Entero sin signo de 8 bits. Longitud
Lon Cab Ext de
la cabecera Enrutamiento en unidades de 8 octetos, no incluye los primeros 8 octetos. Tipo de Enrutamiento variante Enrutamiento. Segmentos Dejados Entero sin signo de 8 bits. Nmero de segmentos de ruta restantes, es decir, nmero de nodos intermedio explcitamente listados an a ser visitados antes de alcanzar el destino final. Campo de longitud variable, de formato determinado por el Tipo de y de longitud tal que la cabecera Enrutamiento completa es un entero mltiplo de 8 octetos de largo. Identificador de 8 bits de una en particular de cabecera
Datos especficos del tipo Enrutamiento,
[Pgina Diciembre
Si, al procesar un paquete recibido, un nodo encuentra una cabecera Enrutamiento con un valor Tipo de Enrutamiento desconocido, el comportamiento requerido del nodo depende del valor del campo Segmentos Dejados, como sigue: Si Segmentos Dejados es cero, el nodo debe ignorar la cabecera Enrutamiento y proceder a procesar la siguiente cabecera en el paquete, cuyo tipo se identifica por el campo Cabecera Siguiente en la cabecera Enrutamiento. Si Segmentos Dejados no es cero, el nodo debe descartar el paquete y enviar un mensaje ICMP Problema de Parmetro, Cdigo 0, a la Direccin Origen del paquete, apuntando al Tipo de Enrutamiento desconocido. Si, despus de procesar una cabecera Enrutamiento de un paquete recibido, un nodo intermedio determina que el paquete ser remitido hacia un enlace cuya MTU de enlace es menor que el tamao del paquete, el nodo debe descartar el paquete y enviar un mensaje ICMP Paquete Demasiado Grande a la Direccin Origen del paquete.
[Pgina Diciembre
La cabecera Enrutamiento de Tipo 0 tiene el siguiente formato: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cabcera Siguien| Lon Cab Ext |Tipo Enrutami=0|Segmentos Dejad| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reservado | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Direccin[1] + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Direccin[2] + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | |
+ Direccin[n] + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Cabecera Siguiente Selector de 8 bits. Identifica el tipo de cabecera que sigue inmediatamente a la cabecera Enrutamiento. Utiliza los mismos valores que el campo Protocolo del IPv4 1700 et seq.]. Lon Cab Ext Entero sin signo de 8 bits. Longitud de la cabecera Enrutamiento en unidades de 8 octetos, sin incluir los primeros 8 octetos. Para la cabecera Enrutamiento de Tipo 0, Lon Cab Ext es igual a dos veces el nmero de direcciones en la cabecera. 0. Track de Estndares Especificacin del IPv6 [Pgina Diciembre
[RFC-
Tipo de Enrutamiento Deering & Hinden 14] RFC 2460 1998 Segmentos Dejados nmero
Entero sin signo de 8 bits. Nmero de segmentos de ruta restantes, es decir, de nodos intermedio explcitamente listados an a ser visitados antes de alcanzar el destino final.
Reservado
Campo reservado de 32 bits. Inicializado a cero para la transmisin; ignorado en la recepcin. Vector de direcciones de 128 bits, numerados desde 1 hasta n.
Direccin[1..n]
Las direcciones multienvo no deben aparecer en una cabecera Enrutamiento de Tipo 0, o en el campo Direccin Destino IPv6 de un paquete que lleva una cabecera Enrutamiento de Tipo 0. Una cabecera Enrutamiento no se examina o procesa hasta que alcance el nodo identificado en el campo Direccin Destino de la cabecera IPv6. En ese nodo, al despachar el campo Cabecera Siguiente de la cabecera inmediatamente precedente ocasiona que el mdulo cabecera Enrutamiento sea invocado, el cual, en el caso de Enrutamiento Tipo 0, lleva a cabo el siguiente algoritmo:
[Pgina Diciembre
si Segmentos Dejados = 0 { proceder a procesar la cabecera siguiente en el paquete, cuyo tipo se identifica por el campo Cabecera Siguiente en la cabecera Enrutamiento } sino si Lon Cab Ext es impar { enviar un mensaje ICMP Problema de Parmetro, Cdigo 0, a la Direccin Origen, apuntando al campo Lon Cab Ext, y descartar el paquete } sino { calcular n, el nmero de direcciones en la cabecera Enrutamiento, al dividir Lon Cab Ext por 2 si Segmentos Dejados es mayor que n { enviar un mensaje ICMP Problema de Parmetro, Cdigo 0, a la Direccin de Origen, apuntando al campo Segmentos Dejados, y descartar el paquete } sino { decrementar Segmentos Dejados en 1; calcular i, el ndice de la direccin siguiente a ser visitado en el vector de direccin, substrayendo Segmentos Dejados de n si la Direccin [i] o la Direccin Destino IPv6 es multienvo { descartar el paquete } sino { intercambiar la Direccin Destino IPv6 y la Direccin [i]
si el Lmite de Saltos es menor que o iguala a 1 { enviar un mensaje ICMP Tiempo Excedido -- Lmite de Saltos Excedido en Transito a la Direccin Origen y descartar el paquete } sino { decrementar el Lmite de Saltos en 1 resometer el paquete al mdulo IPv6 para la transmisin hacia el nuevo destino } } } }
[Pgina Diciembre
Como un ejemplo de los efectos del algoritmo de arriba, considerar el caso de un nodo origen S que enva un paquete al nodo de destino D, usando una cabecera Enrutamiento para causar que el paquete sea enrutado va los nodos intermedio I1, I2, e I3. Los valores de los campos pertinentes de la cabecera IPv6 y de la cabecera Enrutamiento en cada segmento de la ruta de entrega seran como sigue: Conforme el paquete viaja de S a I1: Direccin de Origen = S Direccin de Destino = I1 Lon Cab Ext = 6 Segmentos Dejados = 3 Direccin[1] = I2 Direccin[2] = I3 Direccin[3] = D
Conforme el paquete viaja de I1 a I2: Direccin de Origen = S Direccin de Destino = I2 Lon Cab Ext = 6 Segmentos Dejados = 2 Direccin[1] = I1 Direccin[2] = I3 Direccin[3] = D
Conforme el paquete viaja de I2 a I3: Direccin de Origen = S Direccin de Destino = I3 Lon Cab Ext = 6 Segmentos Dejados = 1 Direccin[1] = I1 Direccin[2] = I2 Direccin[3] = D
Conforme el paquete viaja de I3 a D: Direccin de Origen = S Direccin de Destino = D Lon Cab Ext = 6 Segmentos Dejados = 0 Direccin[1] = I1 Direccin[2] = I2 Direccin[3] = I3
Deering & Hinden 17] RFC 2460 1998 4.5 Cabecera Fragmento
[Pgina Diciembre
La cabecera Fragmento es utilizada por un origen IPv6 para enviar un paquete ms grande de lo que cabra en la MTU de la ruta hacia su destino. (Nota: a diferencia del IPv4, la fragmentacin en el IPv6 slo se lleva a cabo por los nodos origen, no por los enrutadores a lo largo de la ruta de entrega de un paquete -- ver seccin 5.) La cabecera Fragmento se identifica por un valor Cabecera Siguiente de 44 en la cabecera inmediatamente precedente, y tiene el siguiente formato: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cabcera Siguien| Reservado |Dsplazamiento dl Fragment|Res|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identificacin | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Cabecera Siguiente tipo Selector de 8 bits. Identifica el de cabecera inicial de la Parte Fragmentable del paquete original (definido abajo). Usa los mismos valores que el campo Protocolo del IPv4 [EL RFC-1700 ET SEQ.]. Reservado recepcin. Desplazamiento del Fragmento Entero sin signo de 13 bits. El desplazamiento, en unidades de 8 Campo reservado de 8 bits. Inicializado a cero para la transmisin; ignorado en la
octetos, de los datos que siguen a esta cabecera, relativo al comienzo de la Parte Fragmentable del paquete original. Res recepcin. Bandera M Identificacin 1 = ms fragmentos; 0 = ltimo fragmento. 32 bits. Ver descripcin abajo. Campo reservado de 2 bits. Inicializado a cero para la transmisin; ignorado en la
Para enviar un paquete que es demasiado grande para caber en la MTU de la ruta hacia su destino, un nodo origen puede dividir el paquete en fragmentos y enviar cada fragmento como un paquete separado, para ser reensamblado en el receptor.
[Pgina Diciembre
Por cada paquete que ser fragmentado, el nodo origen genera un valor Identificacin. La Identificacin debe ser diferente que el de cualquier otro paquete fragmentado enviado recientemente* con la misma Direccin Origen y Direccin Destino. Si una cabecera Enrutamiento est presente, la Direccin Destino de inters es la del destino final. * "recientemente" significa dentro del mximo tiempo de vida probable de un paquete, incluyendo el tiempo de trnsito del origen hacia el destino y el tiempo gastado esperando el reensemblaje con otros fragmentos del mismo paquete. Sin embargo, no se requiere que un nodo origen conozca el mximo tiempo de vida de un paquete. Ms bien, se asume que el requisito puede encontrarse manteniendo el valor Identificacin como un simple, contador "envoltura alrededor", de 32 bits, incrementado cada vez que un paquete debe fragmentarse. Es una opcin de implementacin si para mantener a un solo contador para el nodo o contadores mltiples, por ejemplo, uno para cada una de las posibles direcciones origen del nodo, o uno para cada combinacin (direccin origen, direccin destino) activa. El paquete inicial, grande, no fragmentado es referido como el "paquete original", y se considera que consiste en dos partes, tal como se ilustra:
paquete original: +------------------+----------------------//----------------------+ | | | | +------------------+----------------------//----------------------+ La Parte No Fragmentable consiste en la cabecera IPv6 ms cualesquiera de las cabeceras de extensin que debe procesarse por nodos en camino hacia el destino, es decir, todas las cabeceras e incluso la cabecera Enrutamiento si esta presente, sino la cabecera Opciones de Salto a Salto si esta presente, sino ninguna de las cabeceras de extensin. La Parte Fragmentable consiste en el resto del paquete, es decir, cualquiera de las cabeceras de extensin que necesita que slo se procese por el nodo(s) destino final, ms la cabecera de capa superior y los datos. La Parte Fragmentable del paquete original es dividida en fragmentos, cada uno, excepto posiblemente el ltimo ("el de la extrema derecha"), siendo un entero mltiplo de 8 octetos de largo. Los fragmentos se transmiten en "paquetes fragmento" separados tal como se ilustra: Deering & Hinden 19] RFC 2460 1998 paquete original: +------------------+--------------+--------------+--//--+---------+ | | | No Fragmentable | fragmento | fragmento | .... | fragmento| +------------------+--------------+--------------+--//--+---------+ paquetes fragmento: +------------------+--------+--------------+ | Parte |Cabecera| primer | | No Fragmentable |Fragment| fragmento | +------------------+--------+--------------+ Parte | primer | segundo | | ltimo Track de Estndares Especificacin del IPv6 [Pgina Diciembre No Fragmentable | Fragmentable Parte | Parte
+------------------+--------+--------------+ | Parte |Cabecera| segundo | | No Fragmentable |Fragment| fragmento | +------------------+--------+--------------+ o o o +------------------+--------+----------+ | Parte |Cabecera| ltimo | | No Fragmentable |Fragment| fragmento| +------------------+--------+----------+ Cada paquete fragmento est compuesto de: (1) La Parte No Fragmentable del paquete original, con la Longitud de la Carga til de la cabecera IPv6 original cambiada para contener la longitud de tan slo este paquete fragmento (excluyendo la longitud de la propia cabecera IPv6), y el campo Cabecera Siguiente de la ltima cabecera de la Parte No Fragmentable cambiado a 44. (2) Una cabecera Fragmento conteniendo: El valor Siguiente Cabecera que identifica la primera cabecera de la Parte Fragmentable del paquete original. Un Desplazamiento del Fragmento que contiene el desplazamiento del fragmento, en unidades de 8 octetos, relativo al comienzo de la Parte Fragmentable del paquete original. El Desplazamiento del Fragmento del primer ("el de la extrema izquierda") fragmento es 0. Una bandera M de valor 0 si el fragmento es el ltimo ("el de la extrema derecha"), sino una bandera M de valor 1. Deering & Hinden 20] RFC 2460 1998 Track de Estndares Especificacin del IPv6 [Pgina Diciembre
El valor Identificacin generado para el paquete original. (3) El propio fragmento. Deben escogerse las longitudes de los fragmentos tal que los paquetes fragmento resultantes quepan dentro de la MTU de la ruta hacia el(los) destino(s) del paquete.
En el destino, se reensamblan los paquetes fragmento en su forma original, no fragmentada, tal como se ilustra: paquete original reensamblado: +------------------+----------------------//----------------------+ | | | | +------------------+----------------------//----------------------+ Las siguientes reglas gobiernan el reensamblaje: Un paquete original slo se reensambla a partir de paquetes fragmento que tienen la misma Direccin Origen, Direccin Destino, e Identificacin del Fragmento. La Parte No Fragmentable del paquete reensamblado consiste en todas las cabeceras, pero sin incluir, la cabecera Fragmento del primer paquete fragmento (es decir, el paquete cuyo Desplazamiento del Fragmento es cero), con los siguiente dos cambios: El campo Cabecera Siguiente de la ltima cabecera de la Parte No Fragmentable se obtiene del campo Cabecera Siguiente de la cabecera Fragmento del primer fragmento. Se calcula la Longitud de la Carga til del paquete reensamblado a partir de la longitud de la Parte No Fragmentable y de la longitud y desplazamiento del ltimo fragmento. Por ejemplo, una frmula para calcular la Longitud de la Carga til del paquete original reensamblado es: LCU.orig = LCU.inicial - LF.inicial - 8 + (8*DF.final) + LF.final donde LCU.orig = campo Longitud de la Carga til del paquete reensamblado. LCU.inicial = campo Longitud de la Carga til del primer paquete fragmento. LF.inicial = longitud del fragmento siguiente a la cabecera Fragmento del primer paquete fragmento. Deering & Hinden 21] RFC 2460 1998 DF.final LF.final cabecera Track de Estndares Especificacin del IPv6 [Pgina Diciembre No Fragmentable | Fragmentable Parte | Parte
= campo Desplazamiento del Fragmento de la cabecera Fragmento del ltimo paquete fragmento. = longitud del fragmento siguiente a la
Fragmento del ltimo paquete fragmento. La Parte Fragmentable del paquete reensamblado se construye a partir de los fragmentos siguientes a las cabeceras Fragmento dentro de cada uno de los paquetes fragmento. La longitud de cada fragmento es calculada substrayendo de la Longitud de la Carga til del paquete la longitud de las cabeceras entre la cabecera IPv6 y el propio fragmento, su posicin relativa en la Parte Fragmentable se calcula a partir de su valor Desplazamiento del Fragmento. La cabecera Fragmento no est presente en el paquete reensamblado, final. Las siguientes condiciones de error pueden originarse al reensamblar paquetes fragmentados: Si se reciben fragmentos insuficientes para completar el reensamblaje de un paquete dentro de los 60 segundos a partir de la recepcin del primer fragmento en llegar de ese paquete, el reensamblaje de ese paquete debe abandonarse y deben descartarse todos los fragmentos que se han recibido para ese paquete. Si el primer fragmento (es decir, el nico con un Desplazamiento del Fragmento de cero) se ha recibido, un mensaje ICMP Tiempo Excedido -- Tiempo Excedido para el Reensamblaje del Fragmento, debe enviarse al origen de ese fragmento. Si la longitud de un fragmento, tal como se dedujo a partir del campo Longitud de la Carga til del paquete fragmento, no es un mltiplo de 8 octetos y la bandera M de ese fragmento es 1, entonces ese fragmento debe descartarse y un mensaje ICMP Problema de Parmetro, Cdigo 0, debe enviarse al origen del fragmento, apuntando al campo Longitud de la Carga til del paquete fragmento. Si la longitud y el desplazamiento de un fragmento son tales que la Longitud de la Carga til del paquete reensamblado de ese fragmento excedera los 65,535 octetos, entonces ese fragmento debe descartarse y un mensaje ICMP Problema de Parmetro, Cdigo 0, debe enviarse al origen del fragmento, apuntando al campo Desplazamiento del Fragmento del paquete fragmento. No se espera que las siguientes condiciones ocurran, pero no se consideran errores si lo hacen:
[Pgina Diciembre
El nmero y contenido de las cabeceras que preceden a la cabecera
Fragmento de fragmentos diferentes del mismo paquete original pueden diferir. Cualesquiera de las cabeceras que estn presentes, precediendo a la cabecera Fragmento en cada paquete fragmento, se procesan cuando los paquetes llegan, previamente a que los fragmentos hagan cola para el reensamblaje. Slo aquellas cabeceras en el paquete fragmento de Desplazamiento cero se retienen en el paquete reensamblado. Los valores Cabecera Siguiente en las cabeceras Fragmento de fragmentos diferentes del mismo paquete original pueden diferir. Slo el valor del paquete fragmento de Desplazamiento cero se usa para el reensamblaje. 4.6 Cabecera Opciones de Destino La cabecera Opciones de Destino es usada para llevar informacin opcional que necesita ser examinada solamente por el(los) nodo(s) destino del paquete. La cabecera Opciones de Destino es identificada por un valor Cabecera Siguiente de 60 en la cabecera inmediatamente precedente, y tiene el siguiente formato: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cabcera Siguien| Lon Cab Ext | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | . . . Opciones . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Cabecera Siguiente Selector de 8 bits. Identifica el tipo de cabecera que sigue inmediatamente a la cabecera Opciones de Destino. Utiliza los mismos valores que el campo Protocolo del IPv4 [RFC-1700 et seq.]. Entero sin signo de 8 bits. Longitud de la cabecera Opciones de Destino en unidades de octetos, no incluye los primeros 8 octetos. Opciones completa es un entero mltiplo de 8 octetos de largo. Contiene uno o ms opciones codificadas TLV, tal como se describe en la seccin 4.2. Las nicas opciones de destino definidas en este documento son las opciones Pad1 y PadN especificadas en la seccin 4.2. Deering & Hinden 23] Track de Estndares [Pgina Campo de longitud variable, de longitud tal que la cabecera Opciones de Destino
Lon Cab Ext 8
RFC 2460 1998
Especificacin del IPv6
Diciembre
Notar que hay dos posibles maneras de codificar informacin de destino opcional en un paquete IPv6: como una opcin en la cabecera Opciones de Destino, o como una cabecera de extensin separada. La cabecera Fragmento y la cabecera Autenticacin son ejemplos de la ms reciente propuesta. Qu propuesta puede ser usada depende de qu accin es deseada de un nodo destino que no entiende la informacin opcional: o paquete direccin multienvo, enviar un mensaje ICMP Tipo No reconocido a la Direccin Origen del paquete, luego la informacin puede ser codificada como una cabecera separada o como una opcin en la cabecera Opciones de Destino cuyo Tipo de Opcin tiene el valor 11 en sus dos bits de ms alto orden. La eleccin puede depender de factores tales como cual toma menos octetos, o cual rinde mejor alineacin o ms eficiente anlisis. o bits de ms alto orden, especificando la accin deseada (ver seccin 4.2). 4.7 Cabecera No Hay Siguiente El valor 59 en el campo Cabecera Siguiente de una cabecera IPv6 o de cualquier cabecera de extensin indica que nada hay siguiendo esa cabecera. Si el campo Longitud de la Carga til de la cabecera IPv6 indica la presencia de octetos ms all del final de una cabecera cuyo campo Cabecera Siguiente contiene 59, esos octetos deben ignorarse, y pasarse inalterados si el paquete se reenva. 5. Cuestiones de Tamao del Paquete El IPv6 requiere que cada enlace en la internet tenga una MTU de 1280 octetos o mayor. En cualquier enlace que no pueda llevarse un paquete de 1280 octetos en una pieza, debe proporcionarse fragmentacin y reensamblaje especifico al enlace en una capa debajo del IPv6. Los Enlaces que tienen una MTU configurable (por ejemplo, enlaces PPP [RFC-1661]) deben configurarse para tener una MTU de por lo menos 1280 octetos; se recomienda que sean configurados con una MTU de 1500 octetos o mayor, para alojar posibles encapsulaciones (es decir, tunelizar) sin incurrir en la fragmentacin de la capa IPv6. Si alguna otra accin es deseada, la informacin debe ser codificada como una opcin en la cabecera Opciones de Destino cuyo Tipo de Opcin tiene el valor 00, 01, o 10 en sus dos Si la accin deseada es que el nodo destino descarte el y, slo si la Direccin Destino del paquete no es una
De cada enlace al cul un nodo se conecta directamente, el nodo debe poder aceptar paquetes tan grandes como la MTU de ese enlace.
[Pgina Diciembre
Se recomienda fuertemente que los nodos IPv6 implementen el Descubrimiento de la MTU de la Ruta [RFC-1981] con el propsito de descubrir y tomar ventaja de las rutas con MTUs mayores que 1280 octetos. Sin embargo, una implementacin IPv6 mnima (por ejemplo, en una ROM de inicio) puede restringirse simplemente a enviar paquetes no ms grandes que 1280 octetos, y omitir la implementacin del Descubrimiento de la MTU de la Ruta. Con el propsito de enviar un paquete ms grande que la MTU de la ruta, un nodo puede utilizar la cabecera Fragmento IPv6 para fragmentar el paquete en el origen y tenerlo reensamblado en el(los) destino(s). Sin embargo, el uso de tal fragmentacin se desalienta en cualquier aplicacin que pueda ajustar sus paquetes para satisfacer la MTU de la ruta medida (es decir, por debajo de los 1280 octetos). Un nodo debe poder aceptar un paquete fragmentado que, despus del reensamblaje, sea tan grande como de 1500 octetos. Se permite a un nodo aceptar paquetes fragmentados de tal manera que reensamblan a ms de 1500 octetos. Un protocolo o aplicacin de capa superior que depende de la fragmentacin IPv6 para enviar paquetes ms grandes que la MTU de una ruta no debe enviar paquetes ms grandes que 1500 octetos a menos que tenga la certidumbre que el destino es capaz reensamblar paquetes de esos tamaos tan grandes. En contestacin a un paquete IPv6 que se enva a un destino IPv4 (es decir, un paquete que experimenta la traduccin del IPv6 al IPv4), el nodo IPv6 originante puede recibir un mensaje ICMP Paquete Demasiado Grande reportando de una MTU del Salto Siguiente menor a 1280. En ese caso, no se exige que el nodo IPv6 reduzca el tamao de los paquetes subsiguientes a menos de 1280, pero debe incluir una cabecera Fragmento en esos paquetes para que el enrutador traductor de IPv6 a IPv4 pueda obtener un valor Identificacin apropiado para usar en los fragmentos IPv4resultantes. Note que esto significa que la carga til puede tener que ser reducida a 1232 octetos (1280 menos 40 para la
cabecera IPv6 y 8 para la cabecera Fragmento), y ms pequea todava si se usan cabeceras de extensin adicionales.
Cabecera de IPv6
La cabecera de IPv6, descrita principalmente en la RFC 2460, elimina o hace opcionales varios campos de la cabecera de IPv4, consiguiendo una cabecera de tamao fijo y ms simple, con el fin de reducir el tiempo de procesamiento de los paquetes manejados y limitar el coste en ancho de banda de la cabecera de IPv6.
Figura 1: Cabecera de IPv4.
La cabecera de IPv4, mostrada en la Figura 1, tiene una longitud variable mnima de 20 octetos. El bit ms significante se numera por 0 a la izquierda, y el menos significante se numera por 31 a la derecha. La forma de transmitir los diferentes bytes, sigue el orden conocido por big endian, es decir, de izquierda a derecha y de arriba abajo segn la estructura presentada en la Figura 1. La cabecera consiste en los siguientes campos:

Versin (4 bits). Es el nmero de versin de IP, es decir, 4. Cabecera (4 bits). Especifica la longitud total de la cabecera en palabras de 32 bits. El valor mnimo y ms comn es de 5, siendo la longitud de cabecera mnima. Puesto que el campo es de 4 bits, se limita la longitud total de la cabecera a 60 bytes. Tipo de servicio (8 bits). Indica la calidad de servicio solicitada por el paquete IP. De los 8 bits, actualmente slo se utilizan 4, indicando cada uno de ellos: conseguir el retardo mnimo, maximizar caudal, maximizar la fiabilidad, y minimizar el coste monetario. Slo uno de estos cuatro bits puede estar a 1. Su uso viene descrito en la RFC 1340 y RFC 1349. Longitud total (16 bits). Especifica el tamao total del paquete, incluyendo la cabecera y los datos, en bytes. Identificador (16 bits). Es un nmero nico asignado por el dispositivo que enva el paquete, con el fin de que el destinatario pueda reensamblar un paquete fragmentado por los nodos intermedios. Recordemos que la fragmentacin es necesaria porque no todas las redes fsicas tienen la misma longitud de trama mxima, por lo cual en muchos casos es necesario que los nodos intermedios dividan el datagrama en varios
fragmentos. Cada uno de estos fragmentos podr seguir rutas distintas al resto y, de perderse alguno de los fragmentos, el origen deber retransmitir el paquete completo. Banderas (3 bits). Es un campo para el control de la fragmentacin. El primer bit no es utilizado y est siempre puesto a 0. Si el segundo bit es 0, significa que puede haber fragmentacin, y si es 1, significa que no puede haber fragmentacin. Si el tercer bit es 0, indica que es el ltimo fragmento, y si es 1, indica que an hay ms fragmentos. Desplazamiento del fragmento (13 bits). Es utilizado en los paquetes que han sido fragmentados, para posibilitar el reensamblado total del paquete. Su valor indica el nmero de bloques de 8 bytes (sin contabilizar los bytes de la cabecera) que estaban contenidos en los fragmentos previos. En el primer fragmento, o en un nico fragmento, este valor es siempre 0. Tiempo de vida (8 bits). Contiene el tiempo mximo que un paquete puede permanecer en una red. Cada dispositivo por el que pasa el paquete decrementa el valor de este campo en el tiempo que tarda en procesar la cabecera IP, siendo 1 el valor mnimo. Si el valor llega a 0, el paquete es descartado. Esto garantiza que los paquetes no viajan a travs de una red haciendo bucles, incluso si las tablas de encaminamiento son errneas. Protocolo (8 bits). Indica al protocolo de nivel superior al que IP deber pasar los datos del paquete. Por ejemplo, UDP es 17 y TCP es 6. Control de errores de la cabecera (16 bits). Es un campo para controlar los errores nicamente en la cabecera IP, exceptuando este campo. Direccin origen (32 bits). Es la direccin del origen del paquete. Direccin destino (32 bits). Es la direccin del destino del paquete. Opciones (variable). No son requeridas en todos los paquetes.
Figura 2: Cabecera de IPv6.
La cabecera bsica de IPv6, mostrada en la Figura 2, tiene una longitud fija de 40 octetos, consistiendo en los siguientes campos:

Versin (4 bits). Es el nmero de versin de IP, es decir, 6. Clase de trfico (8 bits). El valor de este campo especifica la clase de trfico. Los valores de 0-7 estn definidos para trfico de datos con control de la congestin, y de 8-15 para trfico de vdeo y audio sin control de la congestin. Etiqueta del flujo (20 bits). El estndar IPv6 define un flujo como una secuencia de paquetes enviados desde un origen especfico a un destino especfico. Un flujo se
identifica nicamente por la combinacin de una direccin fuente y una etiqueta de 20 bits. De este modo, la fuente asigna la misma etiqueta a todos los paquetes que forman parte del mismo flujo. La utilizacin de esta etiqueta, que identifica una camino a lo largo de la red, posibilita encaminar conmutar en vez de encaminar. Su uso viene descrito en la RFC 1809. Longitud del paquete (16 bits). Especifica el tamao total del paquete, incluyendo la cabecera y los datos, en bytes. Es necesario porque tambin hay campos opcionales en la cabecera. Siguiente cabecera (8 bits). Indica el tipo de cabecera que sigue a la cabecera fija de IPv6, por ejemplo, una cabecera TCP/UDP, ICMPv6 o una cabecera IPv6 opcional. Lmite de saltos (8 bits). Es el nmero de saltos mximo que le quedan al paquete. El lmite de saltos es establecido a un valor mximo por el origen y decrementado en 1 cada vez que un nodo encamina el paquete. Si el lmite de saltos es decrementado y toma el valor 0, el paquete es descartado. Direccin origen (128 bits). Es la direccin del origen del paquete. Direccin destino (128 bits). Es la direccin del destino del paquete.
Como podemos observar, de los 12 campos de la cabecera de IPv4 se ha pasado a 8 campos en IPv6. El motivo fundamental por el que estos campos (tipo de servicio, indicadores, identificacin y control de errores) son eliminados, es la innecesaria redundancia; en IPv4 se est facilitando la misma informacin de diversas formas, como es el caso del campo de control de errores, pues otros mecanismos de encapsulado de capas inferiores, por ejemplo IEEE 802, ya realizan esta funcin. El campo de desplazamiento de fragmentacin de IPv4 ha sido eliminado, porque los paquetes ya no son fragmentados en los nodos intermedios, en IPv6 es un proceso que se produce extremo a extremo. El nico campo realmente nuevo en IPv6 es la etiqueta de flujo. La informacin opcional a la estrictamente necesaria para encaminar los paquetes de datos, es codificada en cabeceras adicionales que pueden ubicarse entre la cabecera IPv6 y las cabeceras de niveles superiores, como por ejemplo la cabecera TCP/UDP. En la actualidad, hay un pequeo nmero de tales cabeceras de extensin (opciones de salto por salto, encaminamiento extendido, fragmentacin y reensamblado, opciones del destino, autentificacin, y encapsulacin) estando cada una identificada por un valor distinto del valor del campo siguiente cabecera. Cada paquete IPv6 puede llevar cero, una, o ms cabeceras de extensin, cada una identificada por el valor del campo siguiente cabecera de la cabecera que la precede. Las cabeceras de extensin deben de ser procesadas en orden, ya que el contenido y semntica de cada una de ellas indican si se debe o no procesar la siguiente cabecera. De esta forma, las cabeceras de extensin no son examinadas o procesadas por los nodos intermedios, slo cuando lleguen al nodo que venga identificado por el campo de direccin de destino de la cabecera IPv6. La nica excepcin es la cabecera de opciones de salto por salto, que lleva informacin que debe ser procesada y examinada en todos los nodos por los que pasa el paquete, incluyendo los nodos origen y destino. La cabecera de opciones de salto por salto, cuando est presente, debe seguir inmediatamente a la cabecera IPv6. Su presencia se indica por el valor 0 en el campo de siguiente cabecera de la cabecera IPv6. Cada cabecera de extensin tiene una longitud mltiplo entero de 8 octetos, con el fin de mantener el alineamiento de 8 octetos en las cabeceras siguientes. La razn de que los
distintos campos de la cabecera estn alineados a 64 bits, es que la nueva generacin de procesadores, de 64 bits, puedan procesar dichos campos ms eficientemente. Resumiendo, las principales mejoras que ofrece la cabecera IPv6 son:

Cabecera de tamao fijo, de 40 bytes. Eliminacin de campos redundantes en la cabecera, haciendo un total de 8. Cabecera bsica y de extensin alineadas a un mltiplo entero de 64 bits. Procesamiento eficiente de las opciones, slo en destino y cuando stas se presentan. Fragmentacin procesada en el origen y el destino de los paquetes, no en los routers.

Direccionamiento VSLM

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Direccionamiento VSLM

Uploaded by

Copyright:

Available Formats

Direccionamiento El direccionamiento es una funcin clave de los protocolos de red que permite la transmisin de datos entre hosts de la misma

Motivacin y orgenes de los IP

Cambios y nuevas caractersticas

Algunos de los cambios de IPv4 a IPv6 ms relevantes son:

Capacidad extendida de direccionamiento

Una ilustracin de una direccin IP (versin 6), en hexadecimal y binario.

son todas vlidas y significan lo mismo, pero

No se debe confundir con:

Identificacin de los tipos de direcciones

192 224 Direccin de Destino 256 288

Opciones salto a salto (Hop-By0 Hop Options)

IPv6 y el Sistema de Nombres de Dominio

Doble pila Tneles Traduccin

Anuncios importantes sobre IPv6

Posicin del Fragmento:

J. Postel 14] RFC 791 1981 Protocolo Internet

Suma de Control de la cabecera solamente. Dado que algunos campos

La direccin de origen. Direccin de Destino:

J. Postel 15] RFC 791 1981 Protocolo Internet

La direccin de destino. Opciones: variable

Ver seccin 3.2.

J. Postel 16] RFC 791 1981 Protocolo Internet

0 slo 0 Restricciones 0 encaminar

Definiciones de Opciones Especficas Fin De La Lista de Opciones

Seguridad (campo S):

uso uso uso uso uso uso uso uso

futuro) futuro) futuro) futuro) futuro) futuro) futuro) futuro)

J. Postel 18] RFC 791 1981 Protocolo Internet

Compartimentos (Campo C): valor

J. Postel 19] RFC 791 1981 Protocolo Internet

J. Postel 20] RFC 791 1981 Protocolo Internet

J. Postel 21] RFC 791 1981 Protocolo Internet

J. Postel 23] RFC 791 1981 Protocolo Internet

Suma de Control de Cabecera

Descripcin de cada uno de los campos

Longitud Total: 16 bits

Actualmente utilizado slo para especificar valores relativos a la fragmentacin de paquetes:

Nmero de opcin: 5 bits. Identificador de la opcin.

Formato de opciones compuesto

Clase Nmero Tamao 0 0 0 0 0 0 0 2 0 1 2 3 9 7 8 4 11

variable Marca de tiempo (Internet Timestamping).

Deering & Hinden 4] RFC 2460 1998

Longitud de la Carga til del

Deering & Hinden 5] RFC 2460 1998

Track de Estndares Especificacin del IPv6

Deering & Hinden 6]

RFC 2460 1998

Especificacin del IPv6

Deering & Hinden 7] RFC 2460 1998

Track de Estndares Especificacin del IPv6

Deering & Hinden 8] RFC 2460 1998 4.2 Opciones

Track de Estndares Especificacin del IPv6

Datos de la Opcin especficos

Cabecera Siguiente cabecera

Lon Cab Ext octetos. Opciones que

Deering & Hinden 11] RFC 2460 1998

Track de Estndares Especificacin del IPv6

Lon Cab Ext de

Datos especficos del tipo Enrutamiento,

Deering & Hinden 12] RFC 2460 1998

Track de Estndares Especificacin del IPv6

Deering & Hinden 13] RFC 2460 1998

Track de Estndares Especificacin del IPv6