Pio Exposicion

PRESENTACION
Protocolo de Internet versión 4 (IPv4) es la cuarta revisión en el desarrollo del

protocolo de Internet (IP) y la primera versión del protocolo a ser ampliamente
desplegado. Junto con IPv6 , es el núcleo de interconexión basado en los
métodos estándares de la Internet. IPv4 es con diferencia la más utilizada de
Internet Capa de protocolo.
Estos aspectos, incluida la integridad de los datos, se inscriben en una capa superior
de protocolo de transporte (por ejemplo, Transmisión Control Protocolo ).
Conjunto de protocolos de Internet
La capa de aplicación
BGP · DHCP · DNS · FTP · HTTP · IMAP · IRC ·

LDAP · MGCP · NNTP · NTP · POP · RIP · RPC · RTP
· SIP · SMTP · SNMP · CALCETINES · SSH · Telnet ·
TLS / SSL · XMPP ·
(Más)
La capa de transporte
TCP · UDP · DCCP · SCTP · Confirmar asistencia ·

REC ·
(Más)
Capa de Internet
IP (IPv4, IPv6 ) · ICMP · ICMPv6 · IGMP · IPsec ·
(Más)
Capa de enlace de
v·d·e
TEORIA DE REDES Pá gina 1

AQUÍ SE ENCUENTRAN
LAS VERSIONES IPV4 Y
IPV6

DEDICATORIA
Este trabajo va dedicado al internet por

facilitarnos los trabajos requeridos y nuestros
padres por el apoyo moral y mutuo que nos
brindaron.
INDICE
Presentación………………………………………………………………………………………………….. pag.1
dedicatoria………………………………………………………………………………………………………pág.2
índice………………………………………………………………………………………………………………pag.3
I PROTOCOLO DE INTERNET VERSION 4 (IPV4)…………………………………………………pag.4
1.Definición………………………………………………………………………………………………………pag.4
2.Direccionamiento………………………………………………………………………………………….pag.4
2.1 Representaciones de direcciones……………………………………………………………….pag.4
2.2 Distribución………………………………………………………………………………………………..pag.5
2.3 Las direcciones de uso personal……………………………………………………………….…pag.5
2.4 Las redes privadas………………………………………………………………………………………pag.6
2.4.2 Las redes privadas virtuales…………………………………………………………………….pag.6
2.5 Local host…………………………………………………………………………………………………..pag.6
3.El agotamiento de direcciones ipv4……………………………………………………………….pag.6
4.traduccion de direcciones de red…………………………………………………………………..pag.7
5.1 Encabezado…………………………………………………………………………………………………pag.7
5.2 Datos………………………………………………………………………………………………………….pag.10
6.Fragmentacion y ensamblado……………………………………………………………………….pag.10
6.1 Fragmentación…………………………………………………………………………………………..pag.10
6.2 Ensamblado o montaje………………………………………………………………………………pag.11

II PROTOCOLO DE INTERNET VERSION “6” (IPV6)-----------------------------------------pag.12
1.definicion-----------------------------------------------------------------------------------------pag.12
2.Motivacion y orígenes del IP-----------------------------------------------------------------pag.13
3. Cambios y nuevas características----------------------------------------------------------pag.13
3.1 Capacidad extendida de direccionamiento--------------------------------------------pag.13
3.2 Autoconfiguración de direcciones libres de estado----------------------------------pag.14
3.3 Multicast----------------------------------------------------------------------------------------pag.14
3.4 Seguridad de nivel de red obligatoria----------------------------------------------------pag.14
3.5 Procesamiento simplificado en los routers---------------------------------------------pag.14
3.6 Movilidad---------------------------------------------------------------------------------------pag.15
3.7 Soporte mejorado para las extensiones y opciones----------------------------------pag.15
3.8 Jumbo gramas---------------------------------------------------------------------------------pag.15
4. Direccionamiento ipv6------------------------------------------------------------------------pag.15
4.1 Notación para las direcciones ipv6-------------------------------------------------------pag.16
4.2 Identificación de los tipos de direcciones-----------------------------------------------pag.17
5. Paquete Ipv6-------------------------------------------------------------------------------------pag.17
5.1 Cabecera fija------------------------------------------------------------------------------------pag.17
5.2 Cabeceras de extensión----------------------------------------------------------------------pag.19
5.3 Carga útil-----------------------------------------------------------------------------------------pag.20
6. IPV6 y el Sistema de nombres de dominio------------------------------------------------pag.20
6.1 Mecanismo de transición al Ipv6-----------------------------------------------------------pag.20
7.Despliegue de IPv6-------------------------------------------------------------------------------pag.21
I PROTOCOLO DE INTERNET VERSION 4 (IPV4)
1.-DEFINICION.- Protocolo de Internet versión 4 (IPv4) es la cuarta revisión en el desarrollo del

protocolo de Internet (IP) y la primera versión del protocolo a ser ampliamente desplegado.
Junto con IPv6 , es el núcleo de interconexión basado en los métodos estándares de la
Internet. IPv4 es con diferencia la más utilizada de Internet Capa de protocolo. A partir de
2011,el despliegue de IPv6 se encuentra todavía en su infancia. IPv4 se describe en el IETF
publicación RFC 791 (septiembre 1981), en sustitución de una definición anterior ( RFC 760 ,
enero de 1980). IPv4 es un protocolo sin conexión para su uso en conmutación de paquetes
Capa de enlace de las redes (por ejemplo, Ethernet ). Funciona en un esfuerzo de la mejor
entrega del modelo, ya que no garantiza la entrega, ni asegurar la secuencia adecuada o evitar
la duplicación de la entrega.

2.-DIRECCIONAMIENTO. IPv4 utiliza 32 - bits (cuatro bytes ) electrónico, que limita el espacio
de direcciones a 4.294.967.296 (2 32) direcciones únicas posibles. Sin embargo, algunos están
reservados para propósitos especiales como redes privadas ( 18 millones de direcciones) o
multicast electrónico (~ 270 millones de direcciones). Esto reduce el número de direcciones
que potencialmente se pueden asignar para el enrutamiento de la Internet pública. Como
direcciones están siendo gradualmente delegado a los usuarios finales, una escasez de
direcciones IPv4 se ha venido desarrollando. El direccionamiento de red rediseño de la
arquitectura a través de red con clase de diseño, Classless Inter-Domain Routing , y de
traducción de direcciones de red (NAT) han contribuido a retrasar de forma significativa el
agotamiento inevitable, pero el 3 de febrero de 2011, dirección de la piscina principal de la
IANA se agotó cuando los últimos cinco bloques fueron asignados a los 5 registros regionales
de Internet (RIR).
Esta limitación ha estimulado el desarrollo de IPv6 , que se encuentra en las primeras etapas
de despliegue, y es la solución a largo plazo solamente.
2.1Representaciones de direcciones. Las direcciones IPv4, simplemente se puede escribir

en cualquier anotación que expresan un poco valor entero-32, pero para la conveniencia
humana, más a menudo escritos en notación decimal con puntos , que se compone de los
cuatro octetos de la dirección expresada por separado en decimales y separados por puntos .
La siguiente tabla muestra los varios formatos de representación.
Notación Valor La conversión de punto decimal

-Notación decimal de 192.0.2.235 N/A
puntos
Punteada hexadecimal Cada octeto es convertido individualmente
0xC0.0x00.0x02.0xEB a hexadecimal
Punteada octal 0300.0000.0002.0353 Cada octeto es individual convertida en
octal
Hexadecimal 0xC00002EB Concatenación de los octetos de
hexadecimal con puntos
Decimales 3221226219 El número de 32 bits expresado en
decimal
Octal 030000001353 El número de 32 bits expresado en octal
Además, en formato de puntos, cada octeto puede ser de cualquiera de las diferentes bases.
Por ejemplo, es un 192.0x00.0002.235 (aunque poco convencionales) equivalente válida para
las direcciones arriba mencionadas.
2.2 Distribución. Originalmente, una dirección IP se divide en dos partes, el identificador de

red representada en los más importantes (el más alto orden) octeto de la dirección y el
identificador de host con el resto de la dirección. Este último fue por lo tanto también se llama
el campo resto. Esto permitió la creación de un máximo de 256 redes. Este se encontró
rápidamente a ser insuficiente.
Para superar este límite, el octeto de orden superior de las direcciones se redefinió para crear
un conjunto de clases de las redes, en un sistema que más tarde se conoció como la creación
de redes con clase . El sistema definido cinco clases, clase A, B, C, D y E. Las clases A, B y C
tuvieron diferentes longitudes de bits para la identificación de red nueva. El resto de la
dirección fue utilizado como anteriormente para identificar un host en una red, lo que significa
que cada clase de red tenía una capacidad diferente para hacer frente a los ejércitos. Clase D
se asignaron multidifusión abordar y Clase E fue reservado para futuras aplicaciones.

A partir alrededor de 1985, los métodos han sido concebidos para permitir que las redes IP
que se subdivide. El concepto de la máscara de subred de longitud variable ( VLSM ) se
introdujo lo que permitió la subdivisión flexible en red de diferentes tamaños. [2] [3]
Alrededor de 1993, este sistema de clases fue reemplazado oficialmente con Classless Inter-
Domain Routing (CIDR), y la basada en esquema de clases se denominó con clase, por el
contrario.
CIDR fue diseñado para permitir volver a crear particiones de cualquier espacio de direcciones
para que los bloques más pequeños o más grandes de las direcciones se podrían asignar a los
usuarios. La estructura jerárquica creada por CIDR es administrado por la Internet Assigned
Numbers Authority (IANA) y los registros regionales de Internet (RIR). Cada RIR mantiene un
público-de búsqueda WHOIS base de datos que proporciona información sobre las
asignaciones de direcciones IP.
2.3 las direcciones de uso personal. Artículo principal: Direcciones IP reservadas #

reservados direcciones IPv4.
CIDR bloque de Descripción

direcciones Referencia
0.0.0.0 / 8 la red actual (solo válido como dirección de RFC 1700
origen)
10.0.0.0 / 8 red privada RFC 1918
127.0.0.0 / 8 Loopback RFC 5735
169.254.0.0/16 Link-local RFC 3927
172.16.0.0/12 red privada RFC 1918
192.0.0.0/24 Reservado (IANA) RFC 5735
192.0.2.0/24 TEST-NET-1, el código de Documentación y RFC 5735
ejemplo
192.88.99.0/24 IPv6 a IPv4 relé RFC 3068
192.168.0.0/16 red privada RFC 1918
198.18.0.0/15 Red de ensayos de referencia RFC 2544
198.51.100.0/24 TEST-NET-2, documentación y ejemplos RFC 5737
203.0.113.0/24 TEST-NET-3, documentación y ejemplos RFC 5737
224.0.0.0 / 4 Multicast (ex red de clase D) RFC 3171
240.0.0.0 / 4 Reservado (Clase antigua red E) RFC 1700
255.255.255.255 Difusión RFC 919
2.4 las redes privadas. De los aproximadamente cuatro millones de direcciones permitidas en
IPv4, tres rangos de direcciones se reservan para su uso en redes privadas . Estos rangos no
están fuera de enrutable de redes privadas y las máquinas privadas no pueden comunicarse
directamente con las redes públicas. Pueden, sin embargo, hacerlo a través de la traducción de
direcciones de red .
Los siguientes son los tres rangos reservados para redes privadas ( RFC una mil novecientas
dieciocho ):
Nombre Rango de Número de Con clase Mayor CIDR

direcciones direcciones descripción bloque
De 24 bits 10.0.0.0- 16 777 216 Una clase individual 10.0.0.0 / 8
de bloque 10.255.255.255
De 20 bits 172.16.0.0- 1 048 576 gama contigua de 172.16.0.0/12
de bloque 172.31.255.255 16 bloques de la
clase B
De 16 bits 192.168.0.0- 65 536 gama contigua de 192.168.0.0/16
de bloque 192.168.255.255 256 bloques de
clase C

2.4.1 las redes privadas virtuales Los paquetes con una dirección de destino privado, son
ignorados por todos los routers público. Por lo tanto, no es posible comunicarse directamente
entre dos redes privadas (por ejemplo, dos sucursales) a través de la Internet pública. Esto
requiere el uso de túneles IP o una red privada virtual (VPN).
Establecer un túnel VPN de conexiones a través de la red pública de tal manera que los
extremos de la función del túnel como routers para los paquetes de la red privada. En esta
función de enrutamiento de acogida encapsula los paquetes en una capa de protocolo con
cabeceras de los paquetes aceptables en la red pública para que puedan ser entregados hasta
el punto extremo opuesto del túnel donde se quita la capa del protocolo adicional y el paquete
se entrega a nivel local a su destino.
Opcionalmente, los paquetes encapsulados pueden ser cifrados para proteger los datos
mientras viajan a través de la red pública.
2.5 local host El rango de direcciones 127.0.0.0-127.255.255.255 (127.0.0.0 / 8 en la notación

CIDR ) está reservado para localhost comunicación. Las direcciones dentro de este rango no
debe aparecer fuera de un equipo host y los paquetes enviados a esta dirección se devuelven
como los paquetes entrantes en el dispositivo de red virtual misma (conocido como bucle ).
3. EL AGOTAMIENTO DE DIRECCIONES IP4
Desde la década de 1980 era evidente que el número de direcciones IPv4 disponibles se están
agotando a un ritmo que no se había previsto inicialmente en el diseño de la red. [4] Esta fue la
motivación para la introducción de redes con clase , para la creación de sin clase Inter-Domain
Routing (CIDR) los métodos y, finalmente, para el rediseño del protocolo de Internet, basado en
un formato de dirección más grande ( IPv6 ).
Varias fuerzas del mercado han llevado a la aceleración del agotamiento de direcciones IPv4:
 creciente número de usuarios de Internet

 Siempre en dispositivos - ADSL módem, módems de cable
 Los dispositivos móviles - ordenadores portátiles , PDAs , teléfonos móviles
Una variedad de tecnologías que se introduzcan durante el crecimiento de Internet se han

aplicado para mitigar el agotamiento de direcciones IPv4 y sus efectos, tales como:
 Network Address Translation (NAT)

 El uso de redes privadas
 Protocolo de configuración dinámica de host (DHCP)
 Basado en nombres de alojamiento virtual
 Un control más estricto por los Registros Regionales de Internet sobre la asignación de
direcciones a los registros locales de Internet
 Red de numeración para recuperar grandes bloques de espacio de direcciones
asignado en los primeros días de Internet
Dirección de la piscina principal de la IANA se había agotado el 3 de febrero 2011, cuando los
últimos cinco bloques fueron asignados a los cinco RIR. [5] [6] APNIC fue el RIR primero en
agotar su grupo regional, el 15 de abril de 2011, a excepción de una pequeña cantidad de la
dirección espacio reservado para la transición a IPv6, que se destinará, en una forma mucho
más restringida. [7]
La solución estandarizada y aceptada es la migración a IPv6 . El tamaño de la dirección se

incrementó en IPv6 de 32 bits de IPv4 a 128 bits, proporcionando un espacio de direcciones
que permite aumentar enormemente la ruta de agregación mejorado a través de Internet y

ofrece subred grandes asignaciones de un mínimo de 2 64 direcciones de host a los usuarios
finales. La migración a IPv6 está en progreso, pero la terminación se espera que tome un
tiempo considerable.
4. TRADUCCION DE DIRECCIONES DE RED
El rápido ritmo de la asignación de las direcciones IPv4 y la consiguiente escasez de espacio

de direcciones desde la década de 1990 llevó a varios métodos para un uso más eficiente. Un
método fue la introducción de la traducción de direcciones de red (NAT). Dispositivos NAT
mascarada toda una red, privada 'detrás' de una sola dirección IP pública, permitiendo el uso
de direcciones privadas dentro de la red privada. La mayor parte del mercado masivo de
consumidores proveedores de acceso a Internet se basa en esta técnica.
5. ESTRUCTURA DE PAQUETES. Un paquete IP se compone de una sección de encabezado

y una sección de datos.
5.1 Encabezado.- La cabecera del paquete IPv4 consta de 14 campos, de los cuales 13 son
obligatorios. El campo 14 es opcional (fondo rojo en la tabla) y el llamado acertadamente:
opciones. Los campos de la cabecera son incluidas con el byte más significativo primero ( big
endian ), y para el diagrama y discusión, los bits más significativos se considera que lo primero
( MSB 0 bits de numeración ). El bit más significativo es el número 0, por lo que el campo de
versión se encuentra realmente en los cuatro bits más significativos del primer byte, por
ejemplo.
poco 0-3 4-7 8-13 14-15 16-18 19-31

desplazamient
o
0 Servicios La longitud total
Versió Longitud diferenciado Notificació
n de la s punto de n explícita
cabecer código de
a congestión
32 Identificación
Bandera Desplazamient
s o de fragmento
64 Tiempo de Vida Protocolo Checksum de la cabecera
96 Dirección IP de origen
128 Dirección IP de destino
160 Opciones (si la longitud de cabecera> 5)
160
o Datos
192 +
Versión.- El campo de cabecera por primera vez en una dirección IP del paquete es el bit de la
versión de campo y cuatro. Para IPv4, esto tiene un valor de 4 (de ahí el nombre de IPv4).
Internet longitud de la cabecera (DIH).- El segundo campo (4 bits) es la Internet Header Length
(DIH) contando el número de 32 bits de palabras en el encabezado. Desde un encabezado
IPv4 puede contener un número variable de opciones, este campo especifica el tamaño de la
cabecera (esto también coincide con el desplazamiento de los datos). El valor mínimo para
este campo es de 5 ( RFC 791 ), que es una longitud de 5 × 32 = 160 bits = 20 bytes. Siendo
un valor de 4 bits, la longitud máxima es de 15 palabras (15 × 32 bits) o 480 bits = 60 bytes.
Servicios diferenciados punto de código (DSCP).- Originalmente definido como el tipo de

servicio de campo, este campo está definido por RFC 2474 para los servicios diferenciados
(DiffServ). Aparecen nuevas tecnologías que requieren datos en tiempo real de transmisión y
por lo tanto hacer uso del campo DSCP. Un ejemplo es la Voz sobre IP (VoIP) que se utiliza
para el intercambio de datos de voz interactiva.

Notificación explícita de congestión (ECN).- Definido en RFC 3168 y permite a extremo la
notificación final de congestión de la red sin dejar caer los paquetes. REC es una característica
opcional que sólo se utiliza cuando los dos extremos de la apoyan y están dispuestos a
utilizarlo. Sólo es efectiva cuando sea compatible con la red subyacente.
La longitud total.- Este campo de 16 bits define el tamaño de datagrama completo, incluida la
cabecera y los datos, en bytes. El datagrama de longitud mínima es de 20 bytes (encabezado
de 20 bytes + 0 bytes de datos) y el máximo es de 65.535 bytes - el valor máximo de una
palabra de 16 bits. El datagrama tamaño mínimo que cualquier equipo debe ser capaz de
manejar es de 576 bytes, pero la mayoría de los ejércitos modernos manejar grandes paquetes
mucho. A veces subredes imponer restricciones sobre el tamaño, en los que los datagramas
caso debe ser fragmentado. La fragmentación se maneja tanto en el interruptor de paquete o
de acogida en IPv4 (ver fragmentación y montaje ).
Identificación.- Este campo es un campo de identificación y se utiliza principalmente para la

identificación exclusiva de fragmentos de un datagrama IP original. Algunos trabajos
experimentales han sugerido utilizar el campo ID para otros fines, como para agregar paquetes
de información de seguimiento a los datagramas con el fin de ayudar a rastrear los datagramas
con direcciones de origen falsa.
Banderas.- Un campo de tres bits sigue y se utiliza para controlar o identificar los fragmentos.
Ellos son (en orden, de orden superior al orden decreciente):
 bit 0: reservado, debe ser cero. [nota 1]
 bit 1: No fragmentar (DF)

 bit 2: Más fragmentos (MF)
Si el indicador DF está establecido y la fragmentación se requiere para enrutar el paquete

entonces el paquete será dado de baja. Esto puede ser usado para enviar paquetes a un host
que no tiene recursos suficientes para manejar la fragmentación. También se puede utilizar
para el Path MTU Discovery , ya sea de forma automática por el software IP de acogida, o de
forma manual utilizando las herramientas de diagnóstico, tales como ping o traceroute . Para
los paquetes no fragmentados, la bandera de MF se borra. Para los paquetes fragmentados,
todos los fragmentos excepto el último que la bandera MF conjunto. El último fragmento tendrá
un distinto de cero campo Fragment Offset, diferenciándolo de un paquete no fragmentado.
Desplazamiento de fragmento.- El campo offset del fragmento, medido en unidades de bloques

de ocho bytes, es de 13 bits y especifica el desplazamiento de un fragmento determinado en
relación con el comienzo del datagrama original no fragmentado de IP. El primer fragmento
tiene un desplazamiento de cero. Esto permite un desplazamiento máximo de (02 13ro al 1ro) x
8 = 65,528 bytes que se exceda el máximo de paquetes IP longitud de 65.535 bytes con la
longitud de la cabecera incluido (65.528 + 20 = 65548 bytes).
Time to Live (TTL).- Un niño de ocho bits tiempo para vivir de campo ayuda a prevenir la
persistencia de datagramas (por ejemplo, ir en círculos) en una internet. Este campo límites de
por vida de un datagrama. Se especifica en segundos, pero los intervalos de tiempo inferior a 1
segundo se redondean a 1. En latencias típicas en la práctica, ha llegado a ser un número de
saltos sobre el terreno. Cada router que un datagrama atraviesa disminuye el campo TTL en
uno. Cuando el campo TTL llega a cero, el paquete ya no es transmitido por un interruptor de
paquete y se descarta. Normalmente, un ICMP mensaje (específicamente el tiempo excedido )
es enviado de vuelta al remitente para informarle de que el paquete ha sido descartado. La
recepción de estos mensajes ICMP se encuentra en el corazón de cómo Ruta de seguimiento
de las obras.
Protocolo.- Este campo define el protocolo usado en la parte de datos de los datagramas IP.
La Internet Assigned Numbers Authority mantiene una lista de números de protocolo IP que se
definió originalmente en RFC 790.

Checksum de la cabecera.- Los 16 bits de control de campo se utiliza para la comprobación de
errores de la cabecera. En cada salto, la suma de comprobación de la cabecera debe ser
comparada con el valor de este campo. Si una suma de comprobación del encabezado se
encuentra para ser no coincidentes, entonces el paquete se descarta. Tenga en cuenta que los
errores en el campo de datos son hasta el protocolo de encapsulado para manejar - de hecho,
tanto UDP y TCP tienen campos de control.
Desde el campo TTL se decremento en cada salto y la fragmentación es posible en cada salto
a continuación, en cada salto la suma de control tendrá que ser recalculada. El método
utilizado para calcular la suma de control se define en RFC 1071 :
El campo de control es la 16 bits de un complemento de complemento a una suma de todas
las palabras de 16 bits en el encabezado. Para efectos del cálculo de la suma de
comprobación, el valor del campo de control es cero.
En otras palabras, todas las palabras de 16 bits se suman entre sí mediante un complemento
(con la comprobación sobre el terreno a cero). La suma es entonces uno de complementarse y
este valor final se añade la comprobación sobre el terreno.
Por ejemplo, el uso 45000030442240008006442e8c7c19acae241e2b hexagonal (20 bytes de
cabecera IP): 4500 + 0030 + 4422 + 4000 + 8006 + 0000 + 8c7c 19ac + + + ae24 1e2b =
2BBCF 2 + = bbcf BBD1 = 1011101111010001, la suma de 1'S = 0100010000101110 = 442E
Para validar una suma de comprobación de cabecera es el mismo algoritmo puede ser
utilizado - la suma de comprobación de la cabecera con la comprobación sobre el terreno
rellenado debe ser una palabra que contiene todos los ceros (valor 0).
Dirección de origen.- Un IPv4 dirección que indica el remitente del paquete. Tenga en cuenta
que esta dirección se puede cambiar en el tránsito por una red de traducción de direcciones de
dispositivo.
Dirección de destino.- Un IPv4 dirección que indica el receptor del paquete. Al igual que con la
dirección de origen, esto puede ser cambiado en tránsito por una red de traducción de
direcciones de dispositivo.
Opciones.- Campos adicionales de cabecera puede seguir el campo de dirección de destino,

pero estos no se utilizan a menudo. Tenga en cuenta que el valor en el campo del derecho
internacional humanitario debe incluir suficientes palabras adicionales de 32 bits para mantener
todas las opciones (además de los de relleno necesarios para garantizar que el encabezado
contiene un número entero de palabras de 32 bits). La lista de opciones puede ser terminada
con un EOL ( Fin de la lista de opciones , 0x00) opción, lo que sólo es necesario si el final de
las opciones de otro modo no coincida con el final de la cabecera. Las posibles opciones que
se pueden poner en la cabecera son los siguientes:
Campo Tamaño Descripción

(bits)
Copiado 1 Se establece en 1 si las opciones deben ser copiados en todos
los fragmentos de un paquete fragmentado.
Opción de 2 A las opciones de categoría general. 0 es para el "control" de
clase opciones, y 2 es de "depuración y la medición". 1, y 3 están
reservados.
Opción 5 Especifica una opción.
Número
Opción de 8 Indica el tamaño de la opción de todo (incluido este campo). Este
longitud campo no puede existir para conocer las opciones simples.
Opción de Variable Datos específicos de la opción. Este campo no puede existir para
datos conocer las opciones simples.
 Nota: Si la longitud de la cabecera es mayor que 5, es decir, está entre 6.15, esto
significa que el campo de las opciones está presente y debe ser considerada.
 Nota: la opción de clase, copiado, y la opción número se refieren a veces como una de
ocho bits solo campo.

5.2 Datos.- La parte de datos del paquete no está incluido en el paquete de control. Su
contenido se interpreta en función del valor del campo de encabezado Protocolo.
En una implementación típica de IP, protocolos estándar como TCP y UDP se implementan en
el núcleo del sistema operativo por razones de rendimiento. Otros protocolos como ICMP
puede ser aplicado en parte por el núcleo, o aplicadas exclusivamente en el software del
usuario. Protocolos no se han aplicado en el núcleo, y no expuestos por las API estándar como
sockets BSD , se implementan normalmente mediante un " conector directo de la API ".
Algunos de los protocolos comunes para la parte de datos son los siguientes:
Protocolo Número Protocolo Nombre Abreviación

1 Internet Control Message Protocol ICMP
2 Grupo de Gestión de Protocolo Internet IGMP
6 Protocolo de transmisión de control TCP
17 Protocolo de datagramas de usuario UDP
41 IPv6 encapsulado -
89 Abrir primero la ruta más corta OSPF
132 Protocolo de transmisión de control de flujo SCTP
6. FRAGMENTACION Y ENSAMBLADO
El Protocolo de Internet es la facilidad en la arquitectura de Internet que permite a las diferentes

redes de intercambio de tráfico y en rutar el tráfico a través de unos a otros. El diseño se
acomoda a las redes de diversa naturaleza física, sino que es independiente de la tecnología
de transmisión de garantía utilizada en la capa de enlace. Vincular las redes de capa de diseño
de hardware diferentes por lo general varían no sólo en la velocidad de transmisión, sino
también en la estructura y el tamaño de los métodos de elaboración de válidos, que se
caracteriza por la unidad de transmisión máxima (MTU) de los parámetros. Para cumplir con el
papel de la PI a las redes de recorrer, es necesario implementar un mecanismo para ajustar
automáticamente el tamaño de las unidades de transmisión para adaptarse a la tecnología
subyacente. Esto introdujo la necesidad de que la fragmentación de los datagramas IP. En
IPv4, esta función se colocó en la capa de Internet , y se realiza en IPv4 routers.
6.1Fragmentacion.- Cuando un dispositivo recibe un paquete IP que examina la dirección de

destino y determina la interfaz de salida para su uso. Esta interfaz tiene una MTU asociados
que determina el tamaño máximo de datos para su carga útil. Si el tamaño de los datos es más
grande que la MTU a continuación, el dispositivo debe fragmentar los datos.
El dispositivo segmentos de los datos en segmentos en los que cada segmento es menor que
o igual a la MTU menos el tamaño de la cabecera IP (20 bytes mínimos, máximo de 60 bytes).
Cada segmento se coloca luego en su propio paquete IP con los siguientes cambios:
 El campo longitud total se ajusta al tamaño del segmento

 Los fragmentos más (MF) está definido para todos los segmentos, excepto el último,
que se establece en 0
 El campo de desplazamiento fragmento se establece de acuerdo basado en el
desplazamiento del segmento en la carga de datos original. Esto se mide en unidades
de bloques de ocho bytes.
 El campo de cabecera de comprobación se vuelve a calcular.
Por ejemplo, para una cabecera IP de una longitud de 20 bytes y un Ethernet MTU de 1.500
bytes de los desplazamientos fragmento sería: 0, (1480 / 8) = 185, (2960 / 8) = 370, (4440 / 8) =
555, (5920 / 8) = 740, etc
Por un azar si cambia un paquete de enlace protocolos de la capa o la MTU reduce entonces
estos fragmentos serían más fragmentados.

Por ejemplo, si una carga útil de 4.500 bytes de datos se inserta en un paquete IP sin opciones
(por lo tanto la longitud total es de 4.520 bytes) y se transmite a través de un enlace con una
MTU de 2500 bytes, entonces se divide en dos fragmentos:
# Longitud total Más fragmentos (MF) Desplazamiento del fragmento

Cabecera Datos
pabellón conjunto?
1 2500 Sí 0
20 2480
2 2040 N 310
20 2020
Ahora, digamos que el MTU se reduce a 1.500 bytes. Cada fragmento individual se divide en
dos fragmentos más cada uno:
# Longitud total Más fragmentos (MF) Desplazamiento del fragmento

Cabecera Datos
pabellón conjunto?
1 1500 Sí 0
20 1480
2 1020 Sí 185
20 1000
3 1500 Sí 310
20 1480
4 560 N 495
20 540
De hecho, la cantidad de datos se ha conservado - 1.480 + 1.000 + 1.480 + 540 = 4500 - y el

último fragmento de desplazamiento (495) * 8 (bytes), además de los datos - 3960 + 540 =
4500 - es también la longitud total.
Tenga en cuenta que los fragmentos 3 y 4 se obtuvieron a partir del fragmento original 2.
Cuando un dispositivo debe fragmentar el último fragmento a continuación, debe establecer el
indicador para todos, pero el último fragmento crea (fragmento 4 en este caso). Último
fragmento se establece en 0 el valor.
6.2 Ensamblado o montaje.- Cuando un receptor detecta un paquete IP en cualquiera de las

siguientes situaciones:
 "Más fragmentos" activada

 "Fragmento de compensar" el campo no es cero
a continuación, el receptor sabe que el paquete es un fragmento. El receptor almacena los

datos en el campo de identificación, el fragmento de compensación, y el indicador "más
fragmentos. Cuando el receptor recibe un fragmento con el indicador "más fragmentos
establece en 0, lo sabe la longitud de los datos originales de carga desde el offset del
fragmento multiplicado por 8 (bytes), más la longitud de datos es equivalente al tamaño de la
carga útil de datos original.
Utilizando el ejemplo anterior, cuando el receptor recibe fragmento 4, el fragmento de

desplazamiento (495 bytes o 3960) y la longitud de datos (540 bytes) suman rendimiento de
4500 - la longitud de datos original.
Una vez que tiene todos los fragmentos de entonces se puede volver a montar los datos en el
orden correcto (mediante el uso de las compensaciones fragmento) y pasarlo a la pila para su
posterior procesamiento.
II PROTOCOLO DE INTERNET VERSION “6” (IPv6)

1.-DEFINICION.-El Internet Protocolo versión 6 (IPv6) (en español: Protocolo de Internet
versión 6) es una versión del protocolo Internet Protocolo (IP), definida en el RFC 2460 y
diseñada para reemplazar a Internet Protocolo versión 4 (IPv4) RFC 791, que actualmente está
implementado en la gran mayoría de dispositivos que acceden a Internet.
Diseñado por Steve Deering de Xerox PARC y Craig Mudge, IPv6 está destinado a sustituir a
IPv4, cuyo límite en el número de direcciones de red admisibles está empezando a restringir el
crecimiento de Internet y su uso, especialmente en China, India, y otros países asiáticos
densamente poblados. El nuevo estándar mejorará el servicio globalmente; por ejemplo,
proporcionará a futuras celdas telefónicas y dispositivos móviles sus direcciones propias y
permanentes.
A principios de 2010, quedaban menos del 10% de IPs sin asignar. En la semana del 3 de
febrero del 2011, la IANA (Agencia Internacional de Asignación de Números de Internet, por
sus siglas en inglés) entregó el último bloque de direcciones disponibles (33 millones) a la
organización 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 número inadecuado para
dar una dirección a cada persona del planeta, y mucho menos a cada vehículo, teléfono, PDA,
etcétera. En cambio, IPv6 admite 340.282.366.920.938.463.463.374.607.431.768.211.456 (2 128
o 340 sextillones de direcciones) —cerca de 6,7 × 1017 (670 mil billones) de direcciones por
cada milímetro cuadrado de la superficie de La Tierra.
Otra vía para la popularización del protocolo es la adopción de este por parte de instituciones.
El gobierno de los Estados Unidos ordenó el despliegue de IPv6 por todas sus agencias
federales en el año 2008
2. Motivación y orígenes de los IP
Durante la primera década de operación de la Internet basada en TCP/IP, a fines de los 80s, se
hizo aparente que se necesitaba desarrollar métodos para conservar el espacio de direcciones.
A principios de los 90s, incluso después de la introducción del rediseño de redes sin clase, se
hizo claro que no sería 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
creación de los grupos de trabajo de "IP de próxima generación" ("IP Next Generation") o
(IPng).
IPng fue propuesto por el Internet Engineering Task Force (IETF) el 25 de julio de 1994, con la
formación de varios grupos de trabajo IPng. Hasta 1996, se publicaron varios RFCs definiendo
IPv6, empezando con el RFC 2460.
La discusión técnica, el desarrollo e introducción de IPv6 no fue sin controversia. Incluso el

diseño ha sido criticado por la falta de interoperabilidad con IPv4 y otros aspectos, por ejemplo
por el científico de la computación D. J. Bernstein.
Incidentalmente, IPng (Ping Pong) no pudo usar la versión número 5 (IPv5) como sucesor de
IPv4, ya que ésta había 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
necesitarán ayuda de un intermediario; vea Mecanismos de Transición más adelante.
3. Cambios y nuevas características

En muchos aspectos, IPv6 es una extensión conservadora de IPv4. La mayoría de los
protocolos de transporte -y aplicación- necesitan pocos o ningún cambio para operar sobre
IPv6; las excepciones son los protocolos de aplicación que integran direcciones de capa de red,
como FTP o NTPv3.
IPv6 especifica un nuevo formato de paquete, diseñado 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 más relevantes son:
3.1 Capacidad extendida de direccionamiento
Una ilustración de una dirección IP (versión 6), en hexadecimal y binario.
El interés de los diseñadores era que direcciones más largas permiten una entrega jerárquica,
sistemática y en definitiva mejor de las direcciones y una eficiente agregación de rutas. Con
IPv4, se desplegaron complejas técnicas de Classless Interdomain Routing (CIDR) para utilizar
de mejor manera el pequeño espacio de direcciones. El esfuerzo requerido para reasignar la
numeración 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 numeración de toda la red, ya que los
identificadores de nodos (los 64 bits menos significativos de la dirección) pueden ser auto-
configurados independientemente por un nodo.
El tamaño de una subred en IPv6 es de 264 (máscara de subred de 64-bit), el cuadrado del
tamaño de la Internet IPv4 entera. Así, las tasas de utilización del espacio de direcciones será
probablemente menor en IPv6, pero la administración de las redes y el ruteo serán más
eficientes debido a las decisiones de diseño inherentes al mayor tamaño de las subredes y la
agregación jerárquica de rutas.
3.2 Autoconfiguración de direcciones libres de estado
Red ruteada en IPv6 usando los mensajes de descubrimiento de routers de ICMPv6. La

primera vez que son conectados a una red, el nodo envía una solicitud de router de link-local
usando multicast (router solicitación) pidiendo los parámetros de configuración; y si los routers
están configurados para esto, responderán este requerimiento con un "anuncio de router"
(router advertisement) que contiene los parámetros de configuración de capa de red.
Si la autoconfiguración de direcciones libres de estado no es adecuada para una aplicación, es

posible utilizar Dynamic Host Configuration Protocolo para IPv6 (DHCPv6) o bien los nodos
pueden ser configurados en forma estática.

Los routers presentan un caso especial de requerimientos para la configuración de direcciones,
ya que muchas veces son la fuente para información de autoconfiguración, como anuncios de
prefijos de red y anuncios de router. La configuración sin estado para routers se logra con un
protocolo especial de re numeración de routers.
3.3 Multicast
Multicast, la habilidad de enviar un paquete único a destinos múltiples es parte de la

especificación 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 dirección
de broadcast y así la dirección más alta de la red (la dirección de broadcast en una red IPv4) es
considerada una dirección 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 características comunes con IPv4, pero también
incorpora cambios y mejoras. Incluso cuando se le asigne a una organización el más pequeño
de los prefijos de ruteo global IPv6, ésta también recibe la posibilidad de usar uno de los 4.2
billones de grupos multicast IPv6 ruteables de fuente específica para asignarlos para
aplicaciones multicast intra-dominio o entre-dominios (RFC 3306). En IPv4 era muy difícil para
una organización conseguir incluso un único grupo multicast ruteable entre-dominios y la
implementación de las soluciones entre-dominios eran anticuadas (RFC 2908). IPv6 también
soporta nuevas soluciones multicast, incluyendo Embedded Rendezvous Point (RFC 3956), el
que simplifica el despliegue de soluciones entre dominios.
3.4 Seguridad de Nivel de Red obligatoria
Internet Protocolo Security (IPsec), el protocolo para cifrado y autenticación 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 tráfico entre routers de BGP IPv6.
3.5 Procesamiento simplificado en los routers
Se hicieron varias simplificaciones en la cabecera de los paquetes, así como en el proceso de

reenvío de paquetes para hacer el procesamiento de los paquetes más simple y por ello más
eficiente. En concreto,
 El encabezado del paquete en IPv6 es más 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 más largas, el encabezado IPv6
(sin opciones) es solamente el doble de largo que el encabezado IPv4 (sin opciones).
 Los routers IPv6 no hacen fragmentación. Los nodos IPv6 requieren ya sea hacer
descubrimiento de MTU, realizar fragmentación extremo a extremo o enviar paquetes
menores al MTU mínimo de IPv6 de 1280 bytes.
 El encabezado IPv6 no está protegido por una suma de comprobación (checksum); la
protección 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 comprobación cada vez que algún 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 cálculo y así pueden hacerlo a velocidad de línea (wirespeed), pero es relevante
para routers por software.
 El campo Tiempo de Vida de IPv4 se llama ahora Límite de Saltos (Hop Limité),
reflejando el hecho de que ya no se espera que los routers computen el tiempo que
específica para asignarlos para aplicaciones multicast intra-dominio o entre-dominios
(RFC 3306). En IPv4 era muy difícil para una organización con el paquete ha pasado
en la cola.
3.6 Movilidad
A diferencia de IPv4 móvil, IPv6 móvil (MIPv6) evita el ruteo triangular y por lo tanto es tan
eficiente como el IPv6 normal. Los routers IPv6 pueden soportar también Movilidad de Red
(NEMO, por Network Mobility) (RFC 3963), que permite que redes enteras se muevan a nuevos
puntos de conexión de routers sin reasignación de numeración. Sin embargo, ni MIPv6 ni
MIPv4 o NEMO son ampliamente difundidos hoy, por lo que esta ventaja es más bien teórica.
3.7 Soporte mejorado para las extensiones y opciones
Los cambios en la manera en que se codifican las opciones de la cabecera IP permiten límites
menos rigurosos en la longitud de opciones, y mayor flexibilidad para introducir nuevas
opciones en el futuro.
3.8 Jumbo gramas
IPv4 limita los paquetes a 64 KiB de carga útil. IPv6 tiene soporte opcional para que los
paquetes puedan superar este límite, los llamados jumbo gramas, que pueden ser de hasta 4
GiB. El uso de jumbo gramas puede mejorar mucho la eficiencia en redes de altos MTU. El uso
de jumbo gramas está indicado en el encabezado opcional Jumbo Payload Option.
4. Direccionamiento IPv6
El cambio más 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 dígitos hexadecimales, que se utilizan
normalmente para escribir las direcciones IPv6, como se describe en la siguiente sección.
El número de direcciones IPv6 posibles es de 2128 ≈ 3.4 x 1038. Este número puede también
representarse como 1632, con 32 dígitos hexadecimales, cada uno de los cuales puede tomar
16 valores.
En muchas ocasiones las direcciones IPv6 están compuestas por dos partes lógicas: un prefijo
de 64 bits y otra parte de 64 bits que corresponde al identificador de interfaz, que casi siempre
se genera automáticamente a partir de la dirección MAC de la interfaz a la que está asignada la
dirección.
4.1 Notación para las direcciones IPv6
Las direcciones IPv6, de 128 bits de longitud, se escriben como ocho grupos de cuatro dígitos
hexadecimales. Por ejemplo,
2001:0db8:85a3:08d3:1319:8a2e:0370:7334
Es una dirección IPv6 válida.
Se puede comprimir un grupo de cuatro dígitos 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 más de dos grupos consecutivos son nulos, también pueden
comprimirse como "::". Si la dirección tiene más de una serie de grupos nulos consecutivos la
compresión sólo se permite en uno de ellos. Así, las siguientes son representaciones posibles
de una misma dirección:
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 válidas y significan lo mismo, pero
2001::25de::cade
-- --
no es válida porque no queda claro cuántos grupos nulos hay en cada lado.
Los ceros iniciales en un grupo también se pueden omitir:
2001:0DB8:02de::0e13
2001:DB8:2de::e13
Si la dirección es una dirección 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 dirección IPv4 mapeada, y el formato ::1.2.3.4 dirección

IPv4 compatible.
Las direcciones IPv4 pueden ser transformadas fácilmente al formato IPv6. Por ejemplo, si la
dirección 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
notación mixta dirección IPv4 compatible, en cuyo caso la dirección debería ser ::135.75.43.52.
Este tipo de dirección IPv4 compatible casi no está siendo utilizada en la práctica, aunque los
estándares no la han declarado obsoleta.
4.2 Identificación de los tipos de direcciones
Los tipos de direcciones IPv6 pueden identificarse tomando en cuenta los primeros bits de cada
dirección.
:: La dirección con todo ceros se utiliza para indicar la ausencia de dirección, y no se asigna
ningún nodo.
::1 La dirección de loopback es una dirección 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 física.

::1.2.3.4 La dirección IPv4 compatible se usa como un mecanismo de transición en las redes
duales IPv4/IPv6. Es un mecanismo que no se usa.
::ffff:0:0 La dirección IPv4 mapeada se usa como mecanismo de transición en terminales
duales.
fe80:: El prefijo de enlace local (en inglés link local) específica que la dirección sólo es válida en
el enlace físico local.
fec0:: El prefijo de emplazamiento local (en inglés site-local prefix) específica que la dirección
sólo es válida dentro de una organización local. La RFC 3879 lo declaró obsoleto,
estableciendo que los sistemas futuros no deben implementar ningún soporte para este tipo de
dirección especial. Se deben sustituir por direcciones Local IPv6 Unicast.
ff00:: El prefijo de multicast. Se usa para las direcciones multicast.
Hay que resaltar que no existen las direcciones de difusión (en inglés broadcast) en IPv6,
aunque la funcionalidad que prestan puede emularse utilizando la dirección multicast FF01::1,
denominada todos los nodos (en inglés all nodes)
5. 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).
5.1 Cabecera Fija
Los primeros 40 bytes (320 bits) son la cabecera del paquete y contiene los siguientes campos:
Offs
et
del 0 1 2 3
Oct
eto
Bit
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
Offs 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
et
Versió Clase de
0 0 Etiqueta de Flujo
n Tráfico
4 32 Longitud del campo de datos Cabecera Siguiente Límite de Saltos
8 64 Dirección de Origen
C 96
10 128

14 160
18 192
1C 224
Dirección de Destino
20 256
24 288
 direcciones de origen (128 bits)

 direcciones de destino (128 bits)
 versión del protocolo IP (4 bits)
 clase de tráfico (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)
 Límite de saltos (8 bits, Tiempo de Vida).
Hay dos versiones de IPv6 levemente diferentes. La ahora obsoleta versión inicial, descrita en
el RFC 1883, difiere de la actual versión propuesta de estándar, descrita en el RFC 2460, en
dos campos: hay 4 bits que han sido reasignados desde "etiqueta de flujo" (flow label) a "clase
de tráfico" (traffic class). El resto de diferencias son menores.
En IPv6 la fragmentación se realiza sólo en el nodo origen del paquete, al contrario que en IPv4
en donde los routers pueden fragmentar un paquete. En IPv6, las opciones también
desaparecen de la cabecera estándar y son especificadas por el campo "Cabecera Siguiente"
(Next Header), similar en funcionalidad en IPv4 al campo Protocolo. Un ejemplo: en IPv4 uno
añadiría la opción "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 modificaría el campo
"Cabecera Siguiente" indicando que viene una cabecera de encaminamiento. La cabecera de
encaminamiento podrá entonces especificar la información adicional de encaminamiento para
el paquete, e indicar que, por ejemplo, la cabecera TCP será la siguiente. Este procedimiento
es análogo al de AH y ESP en IPsec para IPv4 (que aplica a IPv6 de igual modo, por
supuesto).
5.2 Cabeceras de extensión
El uso de un formato flexible de cabeceras de extensión opcionales es una idea innovadora que
permite ir añadiendo funcionalidades de forma paulatina. Este diseño 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 extensión, donde la cabecera fija y las de
extensiones opcionales incluyen el campo de cabecera siguiente que identifica el tipo de
cabeceras de extensión que viene a continuación o el identificador del protocolo de nivel
superior. Luego las cabeceras de extensión 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 extensión. Como resultado de la secuencia anterior, dichas cabeceras de
extensión 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 versión IPv4 un tamaño fijo de 40
octetos.specífica para asignarlos para aplicaciones multicast intra-dominio o entre-dominios
(RFC 3306). En IPv4 era muy difícil para una organización co
Todas o parte de estas cabeceras de extensión tienen que ubicarse en el datagrama en el

orden especificado:
Cabecera de Extensión Tipo Tamaño Descripción RFC
Contiene datos que deben ser

Opciones salto a salto (Hop- examinados por cada nodo a
0 variable RFC 2460
By-Hop Options) través de la ruta de envío de un
paquete.
Métodos para especificar la forma RFC 2460,

Ruteo (Routing) 43 variable de rutear un datagrama. (Usado RFC 3775,
con IPv6 móvil) RFC 5095
Cabecera de fragmentación Contiene parámetros para la

44 64 bits RFC 2460
(Fragment) fragmentación de los datagramas.
Contiene información para

Cabecera de autenticación verificar la autenticación de la
51 variable RFC 4302
(Authentication Header (AH)) mayor parte de los datos del
paquete (Ver IPsec)
Encapsulado de seguridad
de la carga útil Lleva la información cifrada para
50 variable RFC 4303
(Encapsulating Security comunicación segura (Ver IPsec).
Payload (ESP))
Información que necesita ser

Opciones para el destino
60 variable examinada solamente por los RFC 2460
(Destination Options)
nodos de destino del paquete.
No Next Header 59 vacío Indica que no hay más cabeceras RFC 2460
Cada cabecera de extensión debe aparecer como mucho una sola vez, salvo la cabecera de
opción destino, que puede aparecer como mucho dos veces, una antes de la cabecera ruteo y
otra antes de la cabecera de la capa superior.

5.3 Carga Útil
La carga útil del paquete puede tener un tamaño de hasta 64 KB en modo estándar, o mayor
con una opción de carga jumbo (jumbo payload) en el encabezado opcional Hop-By-Hop.
La fragmentación es manejada solamente en el host que envía la información en IPv6: los

routers nunca fragmentan un paquete y los hosts se espera que utilicen el Path MTU discovery.
6. IPv6 y el Sistema de Nombres de Dominio
Las direcciones IPv6 se representan en el Sistema de Nombres de Dominio (DNS) mediante

registros AAAA (también 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 diseñando 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 generalización del DNS IPv4, la idea de A6 fue
una revisión y puesta a punto del DNS para ser más genérico, 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 comparación de las ventajas
y desventajas de cada tipo de registro.
6.1 Mecanismos de transición a IPv6
Ante el agotamiento de las direcciones IPv4, el cambio a IPv6 ya ha comenzado. Se espera

que convivan ambos protocolos durante 20 años y que la implantación de IPv6 sea paulatina.
Existe una serie de mecanismos que permitirán la convivencia y la migración progresiva tanto
de las redes como de los equipos de usuario. En general, los mecanismos de transición pueden
clasificarse en tres grupos:
 Doble pila
 Túneles
 Traducción
La doble pila hace referencia a una solución 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: Fácil de desplegar y extensamente soportado.

 En contra: La topología de red requiere dos tablas de encaminamiento y dos procesos
de encaminamiento. Cada nodo en la red necesita tener actualizadas las dos pilas.
Los túneles permiten conectarse a redes IPv6 "saltando" sobre redes IPv4. Estos túneles
trabajan encapsulando los paquetes IPv6 en paquetes IPv4 teniendo como siguiente capa IP el
protocolo número 41, y de ahí el nombre proto-41. De esta manera, se pueden enviar paquetes
IPv6 sobre una infraestructura IPv4. Hay muchas tecnologías de túneles disponibles. La
principal diferencia está en el método que usan los nodos encapsuladores para determinar la
dirección a la salida del túnel.
La traducción es necesaria cuando un nodo que sólo soporta IPv4 intenta comunicar con un
nodo que sólo soporta IPv6. Los mecanismos de traducción se pueden dividir en dos grupos
basados en si la información 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).
7. Despliegue de IPv6
Varios de los mecanismos mencionados más 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 inglés).

Pio Exposicion

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Pio Exposicion

Hochgeladen von

Copyright:

Verfügbare Formate

PRESENTACION

Protocolo de Internet versión 4 (IPv4) es la cuarta revisión en el desarrollo del

Conjunto de protocolos de Internet

BGP · DHCP · DNS · FTP · HTTP · IMAP · IRC ·

TCP · UDP · DCCP · SCTP · Confirmar asistencia ·

IP (IPv4, IPv6 ) · ICMP · ICMPv6 · IGMP · IPsec ·

TEORIA DE REDES Pá gina 1

TEORIA DE REDES Pá gina 2

Este trabajo va dedicado al internet por

TEORIA DE REDES Pá gina 3

I PROTOCOLO DE INTERNET VERSION 4 (IPV4)

1.-DEFINICION.- Protocolo de Internet versión 4 (IPv4) es la cuarta revisión en el desarrollo del

TEORIA DE REDES Pá gina 4

2.1Representaciones de direcciones. Las direcciones IPv4, simplemente se puede escribir

La siguiente tabla muestra los varios formatos de representación.

Notación Valor La conversión de punto decimal

2.2 Distribución. Originalmente, una dirección IP se divide en dos partes, el identificador de

TEORIA DE REDES Pá gina 5

2.3 las direcciones de uso personal. Artículo principal: Direcciones IP reservadas #

CIDR bloque de Descripción

Nombre Rango de Número de Con clase Mayor CIDR

TEORIA DE REDES Pá gina 6

2.5 local host El rango de direcciones 127.0.0.0-127.255.255.255 (127.0.0.0 / 8 en la notación

3. EL AGOTAMIENTO DE DIRECCIONES IP4

 creciente número de usuarios de Internet

Una variedad de tecnologías que se introduzcan durante el crecimiento de Internet se han

 Network Address Translation (NAT)

La solución estandarizada y aceptada es la migración a IPv6 . El tamaño de la dirección se

TEORIA DE REDES Pá gina 7

4. TRADUCCION DE DIRECCIONES DE RED

El rápido ritmo de la asignación de las direcciones IPv4 y la consiguiente escasez de espacio

5. ESTRUCTURA DE PAQUETES. Un paquete IP se compone de una sección de encabezado

poco 0-3 4-7 8-13 14-15 16-18 19-31

Servicios diferenciados punto de código (DSCP).- Originalmente definido como el tipo de

TEORIA DE REDES Pá gina 8

Identificación.- Este campo es un campo de identificación y se utiliza principalmente para la

 bit 0: reservado, debe ser cero. [nota 1]

 bit 1: No fragmentar (DF)

Si el indicador DF está establecido y la fragmentación se requiere para enrutar el paquete

Desplazamiento de fragmento.- El campo offset del fragmento, medido en unidades de bloques

TEORIA DE REDES Pá gina 9

Opciones.- Campos adicionales de cabecera puede seguir el campo de dirección de destino,

Campo Tamaño Descripción

TEORIA DE REDES Pá gina 10

Protocolo Número Protocolo Nombre Abreviación

El Protocolo de Internet es la facilidad en la arquitectura de Internet que permite a las diferentes

6.1Fragmentacion.- Cuando un dispositivo recibe un paquete IP que examina la dirección de

 El campo longitud total se ajusta al tamaño del segmento

TEORIA DE REDES Pá gina 11

# Longitud total Más fragmentos (MF) Desplazamiento del fragmento

# Longitud total Más fragmentos (MF) Desplazamiento del fragmento

De hecho, la cantidad de datos se ha conservado - 1.480 + 1.000 + 1.480 + 540 = 4500 - y el

6.2 Ensamblado o montaje.- Cuando un receptor detecta un paquete IP en cualquiera de las

 "Más fragmentos" activada

a continuación, el receptor sabe que el paquete es un fragmento. El receptor almacena los

Utilizando el ejemplo anterior, cuando el receptor recibe fragmento 4, el fragmento de

II PROTOCOLO DE INTERNET VERSION “6” (IPv6)

TEORIA DE REDES Pá gina 12

2. Motivación y orígenes de los IP

La discusión técnica, el desarrollo e introducción de IPv6 no fue sin controversia. Incluso el

3. Cambios y nuevas características

TEORIA DE REDES Pá gina 13

Algunos de los cambios de IPv4 a IPv6 más relevantes son: