T Ucsg Pos Mtel 5

SSTEMA DE POSGRADO
MAESTRA EN TELECOMUNCACONES

TTULO DE LA TESS:
PROPUESTA PARA LA TRANSCN DE Pv4 A Pv6 EN EL
ECUADOR A TRAVS DE LA SUPERTEL.

Previa la obtencin del Grado Acadmico de Magster en
Telecomunicaciones

ELABORADO POR:
ng. Jos Coellar Solrzano
ng. Jacob Cedeo Mendoza

Guayaquil, a los 4 das del mes Febrero ao 2013

SSTEMA DE POSGRADO

CERTFCACN
Certificamos que el presente trabajo fue realizado en su totalidad por
los Magsteres Jos Coellar y Jacob Cedeo Mendoza como
requerimiento parcial para la obtencin del Grado Acadmico de
Magster en Telecomunicaciones.

Guayaquil, a los 4 das del mes de Febrero 2013

DRECTOR DE TESS

__________________________________
MsC. Edwin Palacios Melndez

REVSORES:

__________________________________
MsC. Luzmila Ruilova Aguirre.

__________________________________
MsC. Luis Crdova Rivadeneira

DRECTOR DEL PROGRAMA

__________________________________
MsC. Manuel Romero Paz

SSTEMA DE POSGRADO

DECLARACN DE RESPONSABLDAD

NOSOTROS, Jos Coellar Solrzano y Jacob Cedeo Mendoza

DECLARAMOS QUE:

La tesis "PROPUESTA PARA LATRANSCN DE Pv4 A Pv6 EN EL
ECUADOR A TRAVS DE LA SUPERTEL, previa a la obtencin del
grado Acadmico de Magster, ha sido desarrollada en base a una
investigacin exhaustiva, respetando derechos intelectuales de
terceros conforme las citas que constan al pie de las pginas
correspondientes. Consecuentemente este trabajo es de nuestra total
autora.

En virtud de esta declaracin, nos responsabilizamos del contenido,
veracidad y alcance cientfico de la tesis del Grado Acadmico en
mencin.


LOS AUTORES
_____________________

_____________________

SSTEMA DE POSGRADO

AUTORZACN

NOSOTROS, Jos Coellar Solrzano y Jacob Cedeo Mendoza

Autorizamos a la Universidad Catlica de Santiago de Guayaquil, la
publicacin, en la biblioteca de la institucin de la Tesis de Maestra
titulada: "PROPUESTA PARA LATRANSCN DE Pv4 A Pv6 EN EL
ECUADOR A TRAVS DE LA SUPERTEL, cuyo contenido, ideas y
criterios son de nuestra exclusiva responsabilidad y total autora.


LOS AUTORES

_____________________

_____________________

Dedicatoria

El presente trabajo va dedicado
con todo cario a mi familia,
quienes con su esfuerzo y
comprensin me brindaron su
apoyo incondicional durante la
realizacin de este trabajo.


El presente trabajo va dedicado
con todo cario a mi familia que
siempre me ha apoyado en toda
mis decisiones, en especial a mi
esposa Silvia por la motivacin
y paciencia que supo
brindarme.


Agradecimientos
A la Universidad Catlica de
Santiago de Guayaquil que nos
abri sus puertas, al programa
de Maestra en
Telecomunicaciones por la
colaboracin prestada al
presente trabajo de
intervencin, al MsC. Edwin
Palacios Melndez, Director de
Tesis y a nuestros maestros
que con sus sabias
experiencias supieron guiarnos
por el camino del saber.

NDICE GENERAL
Resumen ............................................................................................ 13
Abstract ............................................................................................. 14
Captuo 1! Descripci"n de pro#ecto de inter$enci"n. ................. 1%
1.1. Antecedentes. ....................................................................... 15
1.2. Definicin del problema ........................................................ 16
1.3. Objetivos ............................................................................... 16
1.4. Hiptesis ............................................................................... 17
1.5. etodolo!"a de investi!acin. .............................................. 17
Captuo &! 'rotocoos de Internet I'$4 e I'$(. .............................. 1)
2.1. Historia de #nternet $ protocolo %&'(#' ................................ 1)
2.2. 'rotocolo %&'(#'. ................................................................. 24
2.3. 'rotocolo de #nternet versin 4 *#'v4+ .................................. 27
2.4. 'roblemas con el 'rotocolo de #nternet 4 *#'v4+ .................. 2,
2.5. Historia del 'rotocolo de #nternet versin 6. ......................... 31
2.6. 'rotocolo de internet versin 6 *#'v6+................................... 32
2.6.1. Caractersticas de Pv6. ................................................ 34
2.6.2. Arquitectura del Protocolo de nternet versin 6 (Pv6) . 37
2.6.3. Formato de direcciones Pv6. ........................................ 41
2.6.4. Direccionamiento Pv6. .................................................. 42
2.6.4.1. Unicast .......................................................................... 42
2.6.4.2. Anycast .......................................................................... 45
2.6.4.3. Multicast ........................................................................ 46
2.7. %rad-ctores de direcciones de red *.A%+ en #'v6. ............... 4,
Captuo 3! 'ropuesta de *ecanismo de +ransici"n a I'$( ......... %1
3.1. /a transicin de #'v4 a #'v6 ................................................. 51
3.2. %ipos de mecanismos de intercone0in de #'v4 a #'v6 ....... 53
3.2.1. Dual P Layer ................................................................. 53
3.2.2. Tunneling Pv6 over Pv4. ............................................. 54
3.2.2.1. Encapsulamiento. .......................................................... 57
3.2.2.2. Tnel automtico. .......................................................... 58
3.2.2.3. Tnel Manual. ................................................................ 59
3.2.2.4. Tnel 6to4. .................................................................... 60
3.2.2.5. Tnel 6over4 ................................................................. 63

3.2.2.6. Tnel Teredo ................................................................. 64
3.2.2.7. SATAP .......................................................................... 66
3.3. %ipos de mecanismos de com-nicacin entre #'v4 a #'v6 ... 6)
3.3.1. Mecanismo DSTM. ........................................................ 69
3.3.2. Mecanismo ST. ............................................................ 71
3.3.3. Mecanismo NAT-PT. ..................................................... 73
3.3.4. Mecanismo BS. ............................................................ 75
3.3.5. Mecanismo TRT. ........................................................... 78
3.3.6. Mecanismo Socks64. .................................................... 80
3.3.7. Mecanismo BA. ............................................................ 82
3.4. An1lisis comparativo de los mecanismos de transicin #'v4 a
#'v6222222 ............................................................................ )3
3.4.1. Anlisis comparativo de los mecanismos de
interconexin. .............................................................................. 84
3.4.2. Anlisis comparativo de los mecanismos de
comunicacin. .............................................................................. 85
3.5. #'v6 en el 3c-ador. .............................................................. )6
3.6. 'lan .acional de &ontrol %4cnico a trav4s de 56'37%3/ $
#.%3/. .......................................................................................... )7
Captuo 4! ,imuaciones de mecanismos de transici"n. ............. -&
4.1. 5im-lacin de los mecanismos %-nnel 8ro9er. .................... ,2
4.2. 5im-lacin del mecanismo D-al 5tac9. .............................. 1:4
Captuo %! Concusiones # Recomendaciones. .......................... 1.)
5.1. &oncl-siones. ..................................................................... 1:)
5.2. 7ecomendaciones. ............................................................. 1:,
/ibiogra0a ...................................................................................... 11.
Ane0o A; 'ar1metros de &alidad para la provisin del 5ervicio de
<alor A!re!ado *5<A+ de #nternet. ................................................ 113
Ane0o 8; 'ol"ticas 7e!ionales #'v6 = &#%3/ ................................ 114

NDICE DE 1IG2RA,

Captuo &! 'rotocoos de Internet I'$4 e I'$(
Figura 2. 1: Usuarios de nternet por Regiones Geogrficas 2012. . 21
Figura 2. 2: Diagrama de barras de usuarios de nternet por Regiones
Geogrficas 2012. ............................................................................ 23
Figura 2. 3: Diagrama de barras de suscriptores de Facebook por
Regiones Geogrficas 2012............................................................. 23
Figura 2. 4: dentificacin de las clases de direcciones P. (Malone &
Niall, 2005) .......................................................................................... 25
Figura 2. 5: Encabezado del Pv4. ...................................................... 27
Figura 2. 6: Configuracin de un datagrama Pv4. (Richard Stevens,
2011) ................................................................................................... 27
Figura 2. 7: Datagrama del Pv6. ........................................................ 37
Figura 2. 8: Extensiones de cabeceras de Pv6. ................................. 39
Figura 2. 9: Formato del datagrama Pv4 vs Pv6. .............................. 39
Figura 2. 10: Formato de direcciones Pv6. ........................................ 41
Figura 2. 11: Formato simplificado de direcciones Pv6. ..................... 41
Figura 2. 12: Campos que conforman las direcciones Pv6. ............... 41
Figura 2. 13: Prefijos de red de 32 y 48 bits. ...................................... 42
Figura 2. 14: Direccionamiento (Unicast) local de enlace. .................. 43
Figura 2. 15: Direccionamiento (Unicast) local de enlace en Ethernet.
............................................................................................................ 43
Figura 2. 16: Direccionamiento Unicast. ............................................. 43
Figura 2. 17: Contextos de direcciones Unicast. ................................. 44
Figura 2. 18: Direccionamiento (Anycast) de los routers. ................... 45
Figura 2. 19: Direccionamiento Anycast. ............................................ 46
Figura 2. 20: Direccionamiento (Multicast) para retransmisin mltiple.
............................................................................................................ 46
Figura 2. 21: Direccionamiento Multicast. ........................................... 47

Captuo 3! 'ropuesta de *ecanismo de +ransici"n a I'$(
Figura 3. 1: Esquema del mecanismo Dual P Layer. ......................... 53
Figura 3. 2: Esquema del mecanismo Tunneling Pv6 over Pv4. ....... 55

Figura 3. 3: Esquema del mecanismo Router to Router. .................... 55
Figura 3. 4: Esquema del mecanismo Host to Router. ........................ 56
Figura 3. 5: Esquema del mecanismo Host to Host. ........................... 56
Figura 3. 6: Esquema del mecanismo Host to Host. ........................... 56
Figura 3. 7: Encapsulamiento del datagrama Pv6. ............................ 57
Figura 3. 8: Esquema del tnel 6to4. .................................................. 61
Figura 3. 9: Esquema del tnel entre dos 6to4. .................................. 63
Figura 3. 10: Esquema del tnel 6over4. ............................................ 64
Figura 3. 11: Esquema del tnel Teredo. ............................................ 65
Figura 3. 12: Esquema del tnel SATAP. .......................................... 67
Figura 3. 13: Arquitectura DSTM. ....................................................... 70
Figura 3. 14: mplementacin esquemtica DSTM. ............................ 70
Figura 3. 15: Esquema ST para redes Pv6. ..................................... 72
Figura 3. 16: Esquema ST para redes >>d-al stac9??. .................... 72
Figura 3. 17: Esquema NAT-PT. ......................................................... 73
Figura 3. 18: Esquema del mecanismo BS. ...................................... 75
Figura 3. 19: Esquema del mecanismo TRT. ..................................... 79
Figura 3. 20: Diagrama del mecanismo Socks. .................................. 80
Figura 3. 21: Esquema del proxy Socks64. ....................................... 81
Figura 3. 22: Esquema del mecanismo BA. ...................................... 82

Captuo 4! ,imuaciones de mecanismos de transici"n.
Figura 4. 1: Software gogoCLENT instalado en Windows 7 de 64 bits.
............................................................................................................ 93
Figura 4. 2: Ventana de gogoCLENT Utility. ................................... 94
Figura 4. 3: Status de conexin Broker de gogoCLENT Utility........ 95
Figura 4. 4: Estado de conexin mediante Pv6.................................. 96
Figura 4. 5: Pgina web del Tunnel Broker Pv6. ................................ 97
Figura 4. 6: Creacin regular de un tnel Broker. ............................... 98
Figura 4. 7: Resultados de la redes LAN. ......................................... 102
Figura 4. 8: Ejecucin automtica del tnel Broker. .......................... 102
Figura 4. 9: pconfig del mecanismo tnel Broker. ............................ 103
Figura 4. 10: Creacin regular de un tnel Broker. ........................... 103

Figura 4. 11: Asignacin manual del protocolo de internet versin
(Pv6). ............................................................................................... 104
Figura 4. 12: Pv6 asignada manualmente para establecer >>D-al
5tac9??. ............................................................................................ 105
Figura 4. 13: Fichero para >>D-al 5tac9?? en Linux. ....................... 106
Figura 4. 14: Captura del datagrama Pv6. ....................................... 107
Figura 4. 15: Estructura del encabezado del datagrama Pv6. ......... 107

NDICE DE +A/LA,
Captuo &
Tabla 2. 1:Estadsticas Mundiales del nternet y la Poblacin. ...................... 22
Tabla 2. 2:Usuarios de nternet en Amrica del Sur. ..................................... 22
Tabla 2. 3:Rango de direcciones del Pv4 ..................................................... 26
Tabla 2. 4:Valores asignados para encabezados en Pv6. ............................ 40
Tabla 2. 5:Significado de los bits de mbito. ................................................. 48
Tabla 2. 6:Esquema de direcciones multicast de nodo solicitado .................. 49

Resumen

El nuevo Protocolo de nternet versin 6 (Pv6) actualmente se va a
incluir como soporte P de muchos productos y de los principales
sistemas operativos de ordenador. El protocolo de internet Pv6
inicialmente se lo llam P de siguiente generacin (Png). En realidad
el protocolo de internet Pv6, est formado por especificaciones
definidas por la Fuerza de Tarea de ngeniera de nternet (nternet
Engineering Task Force, ETF).

El protocolo de internet Pv6 fue diseado para mejorar la actual
versin Pv4. Donde los hosts y nodos intermedios puedan operar ya
sea con Pv4 o Pv6, adems de manejar paquetes formateados para
cualquier nivel. Tanto los usuarios como los proveedores de servicio
de internet pueden actualizarse al Pv6 independientemente, sin
tenerse que coordinarse entre s.

El presente trabajo de investigacin consiste en proponer todos los
mecanismos existentes y aceptados internacionalmente para ejecutar
el proceso de transicin de Pv4 a Pv6, todo esto por Decreto
Constitucional y regulado por el CONATEL, MNTEL y SUPERTEL
para posteriormente realizar una migracin total.

14

Abstract

The new nternet Protocol version 6 (Pv6) will be included
as P support of many products and principal operating
systems of computers. Pv6 was initially named Next
Generation P(Png). Actually, internet protocol Pv6 is
formed of specifications defined by the nternet
Engineering Task Force (ETF).

Pv6 internet protocol was designed to improve the
present version Pv4 in which hosts and intermediate
nods can operate with Pv4 or Pv6 in addition to manage
packets formatted for any level. Also, users and internet
service providers can update to Pv6 independently,
without having to coordinate with each other.

The present research consists in proposing every
internationally accepted existing mechanism to execute
the transition process from Pv4 to Pv6, adhering to
Constitutional Decree and following regulations of the
CONATEL, MNTEL and SUPERTEL, in order to later
carry out a complete migration.

15

Captuo 1! Descripci"n de pro#ecto de inter$enci"n.

1.1. Antecedentes.
El Protocolo de nternet con sus siglas en ingls P (nternet
Protocol), permite el funcionamiento de internet, en la actualidad Pv4 se
est agotando inminentemente, la ANA
1
en febrero del 2011 ha
entregado las ltimas direcciones Pv4 a cada una de las cinco regiones,
previndose el agotamiento en Suramrica para el ao 2012.

Actualmente el internet usa el protocolo Pv4 con 4.000 millones de
direcciones pblicas, con lmite prctico de aproximadamente 300
millones, donde cada conexin a internet usa una direccin pblica,
aunque sea compartida a travs de un dispositivo NAT. Hace algunos
aos atrs se pens que ocurrira este inconveniente, presentndose
una solucin estandarizada, la misma que ha sido puesta en evaluacin
y comprobada para estar disponible en los equipos de usuarios finales y
operadores, conocida como la nueva versin del protocolo de internet
Pv6, la misma nos garantizara un despliegue del ancho de banda
durante 480 aos aproximadamente.

El mencionado protocolo ha comenzado desplegndose en el
continente Europeo aproximadamente desde el 2002, pero la
penetracin en Suramrica es prcticamente inexistente y en pases en
va de desarrollo se est quedando rezagado. Los planes de expansin
de banda ancha en Ecuador, no podrn cumplirse si no se toman
medidas urgentes que garantice a la administracin pblica, proveedores
de contenidos, SPs y la industria en general, toma conciencia del
problema.

Se restringe la asignacin de direcciones pblicas, es decir, de
asignar clases A, B y C se pas a la asignacin de bloques de

1
IANA3 Internet Assigned Numbers Aut4orit# es la entidad que supervisa la
asignacin global de direcciones P, por Jon Postel en el nstituto de Ciencias de la
nformacin (S).

16

direcciones ajustadas a las necesidades, la RR sugiere el uso de
direcciones dinmicas o privadas, y que se restringa el uso de
direcciones pblicas, salvo los casos en que los servicios cliente-servidor
justifique la necesidad. En las eventuales congestiones producidas por el
trfico entre host o terminales de distintas redes, cada paquete de
informacin compite por obtener un poco de ancha de banda disponible
para alcanzar su destino.

1.&. De0inici"n de probema
Debido al agotamiento de protocolos de internet Pv4 en
Latinoamrica, especficamente en el Ecuador surge la necesidad de
realizar la transicin de PV4 a PV6 a travs del Ministerio de
Telecomunicaciones mediante la Superintendencia de
Telecomunicaciones (SUPERTEL).

1.3. 5b6eti$os
Una vez que se ha definido el problema de investigacin
procedemos a describir el objetivo general y los objetivos especficos.

1.3.1. 5b6eti$o Genera!
Proponer los mecanismos de transicin de PV4 a PV6 para
mejorar la interconexin y comunicacin de las operadoras de servicios
de valor agregado de internet en el Ecuador.

1.3.&. 5b6eti$os espec0icos!
Describir el estado del arte de los protocolos de internet Pv4 e
Pv6.
Determinar el mecanismo para la migracin o transicin del
protocolo de internet Pv4 a Pv6.
Evaluar el funcionamiento de Pv4 versus Pv6 mediante una red
donde coexistan ambos protocolos.

17

1.4. 7ip"tesis
La presente propuesta de los mecanismos de transicin del
protocolo de internet Pv4 a Pv6 permitir un adecuado crecimiento de
la banda ancha del internet y mejorar la calidad de transmisin de la
informacin.

1.%. *etodooga de in$estigaci"n.
Acance!
La presente investigacin es de carcter E8poratorio #
E8picati$o3 pues se pretende explorar a los protocolos de internet Pv4
e Pv6 a travs del estado del arte que originan el fenmeno en cuestin,
y pretender una explicacin del mismo. Tambin interesa emplear
alguna herramienta de simulacin para comprobar tal fenmeno.

'aradigma:
Emprico-Analtico con enfoque cuantitativo.

*9todo!
Ex post facto, puesto que se pretender evidenciar las posibles
relaciones de causa efecto entre las tcnicas o mecanismos de
transicin para interconexin y comunicacin de PV4 a PV6.

Dise:o de a In$estigaci"n!
No e8perimenta +rans$ersa.- Puesto que no se manipularn
deliberadamente las variables de estudio, se proceder a la observacin
directa de los protocolos de internet tal y como se da en su contexto
natural, y posteriormente su anlisis respectivo.

18

Captuo &! 'rotocoos de Internet I'$4 e I'$(.

En el presente captulo se basa en los servicios estandarizados
llamados Protocolos de nternet (P) versiones 4 y 6, presentaremos
tambin el esquema de direccionamiento usado por el P y explicaremos
la divisin de las clases de direcciones del P. Adicional detallamos un
aspecto del protocolo como TCP e P brindan las frmulas para
transmisin de mensajes, y lo que es ms importante, se discutirn los
estndares de comunicacin, independientemente de hardware de la red.

&.1. 7istoria de Internet # protocoo +C';I'
En realidad nternet es un medio de comunicacin que revoluciona el
mundo tanto de las telecomunicaciones como de los ordenadores o
computadoras. Las bases que permitieron su desarrollo o evolucin,
inicialmente desde el telgrafo hasta las computadoras personales
pasando por el telfono y la radio
2
. La cantidad de informacin que
maneja en la actualidad nternet es demasiado grande, siendo utilizado
como un recurso investigativo cuyo acceso de informacin mundial se lo
realiza en pocos segundos.

nternet inicialmente fue ideada por J. C. R. Licklider, que mediante
oficios escritos en Agosto de 1962 en el nstituto Tecnolgico de
Massachusetts (MT), describa computadores que se conectaban entre
s, para acceder a la toda la informacin entre las misma, tambin
denominada por l como una Red Galctica (Galactic Network). Debido a
estas ideas radicales Licklider fue designado Director del Programa
DARPA *Defense Advanced 7esearc@ 'rojects A!enc$+.

El protocolo TCP/P fue diseado a finales de 1960 como el
fundamento de la red ARPANET, que conectaba las computadoras de
oficinas gubernamentales y universitarias. Funcionaba bajo el concepto

2
Recuperado de la pgina web: http://www.iab.org/

19

de cliente servidor, lo que significa que alguna computadora pide los
servicios de otra computadora; la primera es el cliente y la segunda el
servidor.(Trejo Ramrez, 2012)

En 1961, Leonard Klienrock introduce el concepto de Conmutacin
de Paquetes (Packet Switching, en ingls). La idea era que la
comunicacin entre ordenadores fuese dividida en paquetes. Cada
paquete debera contener la direccin de destino y podra encontrar su
propio camino a travs de la red(Urea Poirier & Rodrguez Martn, 2012).

En octubre de 1962, Licklider fue nombrado jefe de la oficina de
procesado de informacin de la Agencia de Proyectos de nvestigacin
Avanzada *Defense Advanced 7esearc@ 'rojects A!enc$ o DARPA), y
empez a formar un grupo informal dentro de DARPA del Departamento
de Defensa de los Estados Unidos para investigaciones sobre
ordenadores ms avanzadas.

Segn lo indicado por (Verdejo Alvarez, 2000), la primera WAN
*Aide Area .etBor9C 7ed de Drea Amplia+ documentada fue creada en
1965 por Lawrence G. Roberts y Thomas Merrill, quienes conectaron una
TX-2 y un Q-32 desde el MT en Massachusetts hasta California mediante
una lnea telefnica. Para 1967 se haba avanzado en el diseo de redes
de comunicaciones, otros pases como nglaterra investigaban por medios
de otros grupos como el RAND y el NPL. Es por esto, que en DARPA se
acord interconectar todos sus centros investigativos por medio de una
red a la que fue denominada ARPANET.

Como parte del papel de la oficina de procesado de informacin, se
instalaron tres terminales de redes: una para la 5$stem Development
&orporation en Santa Mnica, otra para el Proyecto Eenie en la
Universidad de California (Berkeley) y otra para el proyecto -ltics en el
nstituto Tecnolgico de Massachusetts. La necesidad de Licklider de
redes se hara evidente por los problemas que esto caus.(UPF, 2012)

20

Ya para el ao 1969 la Agencia de Proyectos de nvestigacin
Avanzada (Defense Advanced 7esearc@ 'rojects A!enc$ o DARPA) del
Ejrcito de los EEUU desarrolla la ARPANET(Urea Poirier & Rodrguez
Martn, 2012). La finalidad principal de esta red era la capacidad de
resistir un ataque nuclear de la URSS para lo que se pens en una
administracin descentralizada. De este modo, si algunos ordenadores
eran destruidos, la red seguira funcionando. Aunque dicha red
funcionaba bien, estaba sujeta a algunas cadas peridicas del sistema.

De este modo, la expansin a largo plazo de esta red podra resultar
difcil y costosa. Se inici entonces una bsqueda de un conjunto de
protocolos ms fiables para la misma. Dicha bsqueda finaliz, a
mediados de los 70, con el desarrollo de TCP/P(Urea Poirier &
Rodrguez Martn, 2012). Es por esto, que se inicia la investigacin en
desarrollar productos de redes de computadoras, y de la tecnologa de
comunicacin, denominada tambin como conmutacin de paquetes, y
finalmente surge el protocolo TCP/P. Entre los objetivos principales se
encontraban los siguientes:
'rotocoos Comunes! que permita el protocolo comn la
comunicacin de todas las redes para simplificacin de los
procesos.
Interoperabiidad! que funcionen correctamente los equipos de
distintos fabricantes y de manera conjunta, permitiendo el
desarrollo eficiente y fomentando la competitividad entre los
proveedores.
Comunicaciones s"idas! que los protocolos aporten con
conexiones fiables y de alto rendimiento mediante redes de rea
extensa relativamente primitivas disponibles en aquel momento.
1aciidad de recon0iguraci"n! que la red permita
reconfigurarse, es decir, facilidad para aadir o eliminar
computadores sin sufrir interrupciones de comunicaciones.

Tras varias investigaciones realizadas, se asigna roles al protocolo
TCP/P, donde solamente P se encargara de enviar paquetes a travs

21

de una red de comunicaciones hacia su destino. Mientras que para
controlar el flujo de informacin o que lleguen los paquetes correctamente
al destino se emplean los 2 protocolos, el TCP y el UDP *6ser Data!ram
'rotocol+, en esencia son el mismo, aunque el segundo no permite que
todos los paquetes lleguen a su destino, solamente una parte, es decir, no
es confiable. Los grupos encargados para desarrollar el nuevo protocolo
se encontraban en las Universidades de Stanford y UCLA que inclua a la
empresa 8oltC 8eranec9 F .eBman *88.+, cuya designacin fue
autorizada por la DARPA.(Verdejo Alvarez, 2000)

Los usuarios de nternet por Regiones Geogrficas se muestra en la
figura 2.1, donde Asia tiene la mayor cantidad de usuarios con el 44,8%;
Europa con el 21,5%, Amrica 22,6% (Norte Amrica 12% y
Latinoamrica 10,6%), frica 7%, Medio Oriente 3,75 y Oceana el 1,9%.
Estos porcentajes se basaron en la informacin a priori de 2,405,518,376
usuarios de nternet hasta junio 30 del 2012.

Figura 2. 1: Usuarios de nternet por Regiones Geogrficas 2012.
Fuente: www.exitoexportador.com/stats.htm

En la tabla 2.1 se muestran las Estadsticas de Usuarios Mundiales
del nternet que fueron actualizadas a Junio 30, 2012 en la pgina web
www.exitoexportador.com/stats. De donde los datos de poblacin se
basan en cifras para 2012 del 65 &ens-s 8-rea-
(http://www.census.gov/) en su mayora. Asimismo, la informacin de los
datos de los usuarios provienen de las siguientes instituciones: Nielsen
Online *@ttp;((BBB.nielsenGonline.com(intlpa!e.@tml+C por la TU
*BBB.it-.int(+, por nternet World Stats
*@ttp;((BBB.internetBorldstats.com(+ y algunas fuentes locales. Finalmente

22

los usuarios o suscriptores de Facebook fueron obtenidos en dicha
organizacin.
Tabla 2. 1:Estadsticas Mundiales del nternet y la Poblacin.
Regiones
'obaci"n
<&.1& Est.=
2suarios
Dic. 313 &...
2suarios
>unio 3.3 &.1&
? 'obaci"n
<'enetraci"n=
2suarios
? *undia
1aceboo@
,ept 3.3 &.1&
A0rica 1,073,380,925 4,514,400 1(B333%3(B( 15.6 % 7.0 % 48,262,820
Asia 3,922,066,987 114,304,000 13.B(3()13.%- 27.5 % 44.8 % 235,989,160
Europa 820,918,446 105,096,093 %1)3%1&31.- 63.2 % 21.5 % 243,230,440
5riente *edio 223,608,203 3,284,800 -.3...34%% 40.2 % 3.7 % 22,793,140
Norte Am9rica 348,280,154 108,096,800 &B33B)%3413 78.6 % 11.4 % 184,177,220
Latinoam9rica ;
Caribe
593,688,638 18,068,919 &%43-1%3B4% 42.9 % 10.6 % 188,339,620
5ceana ;
Austraia
35,903,569 7,620,480 &43&)B3-1- 67.6 % 1.0 % 14,614,780
+5+AL *2NDIALB3.1B3)4(3-&& 3(.3-)%34-& &34.%3%1)33B( 34.3 ? 1.... ? -3B34.B31).

En Ecuador la poblacin es aproximadamente de 15 millones, los
usuarios de internet al ao 2000 fue de 180 mil, mientras que en el 2012
superan los 6 millones, cuyo porcentaje de penetracin en la poblacin es
43,8% y hay aproximadamente 5 millones de suscriptores en Facebook,
esta informacin se observa detalladamente en la tabla 2.2 de usuarios de
internet en Amrica del Sur.
Tabla 2. 2:Usuarios de nternet en Amrica del Sur.
Am9rica de ,ur
'obaci"n
<dato &.1&=
2suarios3
a:o &...
2suarios
>unio 3.3 &.1&
'enetraci"n
<? 'obaci"n=
2suarios
? +aba
1aceboo@
,ept 3.3 &.1&
Argentina 42,192,494 &3%..3... &)3...3... ((.4 ? 14.B ? &.3.4)31..
/oi$ia 10,290,003 1&.3... 33.)B3... 3... ? 1.( ? 13B%33.(.
/rasi 193,946,886 %3...3... ))34-43B%( 4%.( ? 4(.( ? %)3%(%3B..
C4ie 17,067,369 13B%B34.. 1.3...3... %).( ? %.3 ? -3()B3B&.
Coombia 45,239,079 )B)3... &(3-3(3343 %-.% ? 14.& 1B33&&3...
Ecuador 15,223,680 1).3... (3((33%%) 43.) ? 3.% ? 43-B.3().
Isas *a$inas 2,995 C &3))B -(.4 ? ... ? &3.&.
Gu#ana 1rancesa 249,540 &3... (B3&&. &(.- ? ... ? (B3&&.
Gua#ana 782,105 33... &%.3&B4 3&.. ? ..1 ? 1343)..
'aragua# 6,541,591 &.3... 13%(3344. &3.- ? ..) ? 13&143.).
'erD 29,549,517 &3%..3... 1.3B)%3%B3 3(.% ? %.B ? -33%134(.
,uriname 560,157 113B.. 1B-3&%. 3&.. ? ..1 ? --3)&.
2rugua# 3,316,328 3B.3... 13)%%3... %%.- ? 1.. ? 13(4(3B4.
EeneFuea 29,497,483 -%.3... 1&3.-B31%( 41.. ? (.4 ? -3B((3%4.
+5+AL,. Am9rica 3-434%-3&&B 143&-&31.. 1)-3-)&34%B 4).& ? 1.... ? 1343(&-3-4.

2

De acuerdo a los datos proporcionados por la tabla 2.1, en la figura
2.2 se muestra el diagrama de barras de los usuarios de internet en el
mundo por zonas geogrficas y en la figura 2.3 se muestra los
suscriptores de Facebook.

Figura 2. 2: Diagrama de barras de usuarios de nternet por Regiones
Geogrficas 2012.

Figura 2. 3: Diagrama de barras de suscriptores de Facebook por Regiones
Geogrficas 2012.

24

Segn los expertos, la nternet como la conocemos, se enfrentar a
un grave problema en unos pocos aos. Debido a su rpido crecimiento y
las limitaciones en su diseo, habr un momento en que no hay
direcciones ms libres estn disponibles para conectar a nuevos
huspedes. En ese punto, no hay servidores web ms nuevas se pueden
crear, sin ms usuarios pueden inscribirse para las cuentas de los SP, y
no mquinas ms nuevas pueden ser configurados para acceder a la web
o participar en juegos en lnea - algunas personas pueden llamar a este
un problema grave.(Feyrer, 2001)

&.&. 'rotocoo +C';I'.
Una vez conocida la historia y de cmo se organiza NTERNET,
procederemos a describir los protocolos que permiten su funcionamiento
universal, independientemente de los computadores, sistemas operativos
y/o redes que la conforman. A continuacin, definiremos los protocolos
TCP/P extrada de (Richard Stevens, 2011): H/as familias de protocolos
%&'(#' permiten la com-nicacin entre diferentes tipos de ordenadores
con independencia del fabricanteC red a la I-e se enc-entren conectados
$ sistema operativo -tiliJado.K

El protocolo de nternet, es un protocolo que no se encuentra
orientado a la conexin para transmisin de informacin mediante una red
de paquetes de datos conmutados. Se encuentra localizado en la tercer
capa del modelo SO/OS, el cual permite entregar paquetes de datos
desde un nodo de origen a otro nodo destino, basado en la direccin
escrita en cada paquete.

La mencionada capa de red de acuerdo al modelo TCP/P, se
emplea los protocolos pertenecientes a la capa de transporte (TCP),
permitiendo orientar los datos hacia un destino especfico, direccionando
los datagrama generados en la capa de red, pero sin poder comprobar la
integridad del contenido.

25

Con lo descrito no se poda distinguir las versiones del P, aunque
con la llegada o aparicin de la versin 6, se empez a diferenciar el Pv6
de la Pv4, sta versin cuenta con una longitud de 32 bits. Dicha longitud
se escribe mediante la forma dottedI-ad (a, b, c, d) que es representado
por el nmero decimal en el intervalo de 0 a 255, es decir, que el rango se
escribe desde 0.0.0.0 hasta 255.255.255.255, lo que es una limitante en
la actualidad ya que existe combinaciones del tipo 2
52
= 4.294.967.296 o
sea 4 billones de direcciones.

Las clases 'a', 'b' y 'c' han sido divididas en partes fijas, dichas
divisiones son muy conocidas en el rango ya mencionado anteriormente.
Adicionalmente, existen direcciones del tipo 'd' y 'e' (ver figura 2.4),
reservadas para procesos multicast y experimentales. La direccin de
clase 'A' tiene 8 y 24 bits, que permite identificar la red y los usuarios
respectivamente. (Malone & Niall, 2005)

Figura 2. 4: dentificacin de las clases de direcciones P.<*aone G Nia3 &..%=

Segn Roberto Gordo, las clases de direccin se encuentran en una
P determinada, siempre depender del rango en l que caiga, segn lo
mostrado en la tabla 2.3.(Gordo Saez, 1998)

26

Tabla 2. 3: Rango de direcciones del Pv4
Case Rango de direcci"n
? direcciones
disponibes en
I'$4
A
0.0.0.0
127.255.255.255
50
/
128.0.0.0
191.255.255.255
25
C
192.0.0.0
223.255.255.255
12.5
D
224.0.0.0
239.255.255.255
6.5
E
240.0.0.0
255.255.255.255
6
Fuente: (Gordo Saez, 1998)

Una vez elegido el tamao de direcciones P y la divisin de cada
direccin dada en dos partes, primeramente el prefijo requiere suficientes
bits para admitir la concesin de la direccin de red nica en nternet.
Ahora, para el sufijo se necesitan demasiados bits para cada una de las
computadoras que se encuentran conectadas a la red cuyo sufijo es nico
(Kotal, 2005). No existe la solucin integral, ya que al agregar bits a una
parte se los disminua de la otra. Finalmente, se puede decir, que un
prefijo grande direccin a muchas redes, aunque limita el tamao de cada
red; mientras que el sufijo grande, indica a la red que puede contar con
muchas computadoras, reduciendo as la cantidad total de redes.

En la figura 2.4 se muestran las cinco clases de direccin; los bits de
la izquierda identifican las clases y la divisin el prefijo y el sufijo,
siguiendo la convencin de los protocolos TCP/P, debemos numerar los
bits de izquierda a derecha y de numerar como cero el primer bit. Las
clases A, B y C se denominan clases primarias, porque emplean
direcciones de host. La clase D se utiliza para multitransmisin, lo que
permite la entrega a un grupo de computadoras. Para pasar
multitransmisin P, un grupo de host debe acordar compartir una
direccin multitransmisin. Una vez establecido el grupo multitransmisin,
se entrega a los host del grupo copia de los paquetes enviados a esta
direccin.

27

&.3. 'rotocoo de internet $ersi"n 4 <I'$4=
El protocolo de internet P, es la parte fundamental sustentada por el
sistema TCP/P y de todo el funcionamiento de NTERNET. Su
especificacin est recogida en la siguiente pgina web http://www.rfc-
es.org/rfc/rfc0791-es.txt.Launidad de datos del P es el datagrama, cuyo
esquema se muestra en la figura 2.5.

Figura 2. 5: Encabezado del Pv4.
Fuente: http://www.imaginar.org/mdi/docs/ipv6.pdf

En la figura 2.5 se ilustra a un datagrama P, cuya estructura es en
bloques de 32 bits (4 bytes), su transmisin consiste en enviar primero el
bit 0, luego el bit 1, 2, 3.hasta finalizar el datagrama. Dicho orden se
denomina netBor9 b$te order, el mismo es muy importante, debido a que
los diferentes computadores tienen diversos sistemas de almacenamiento
de bits en memoria. Otro formato es el little endian, que permite
almacenar bits en orden inverso al netBor9 b$te order, mientras que la
otra posibilidad se denomina 8i! endian.

Segn el modelo TCP/P el protocolo de capa 3 permite direccionar
los datagramas en la capa de red, este encabezado se superpone al
datagrama manejado, es decir, las caractersticas de ruteo y transmisin.
En la capa inmediatamente superior a TCP se agrega el encabezado,
quedando el datagrama tal y como se muestra en la figura 2.6:

Figura 2. 6: Configuracin de un datagrama Pv4. (Richard Stevens, 2011)

28

La longitud que tiene el encabezado P en la capa de red es de 170
bits, que aproximadamente es 20 bytes, formada por diversos campos con
distintos significados(Gordo Saez, 1998)ilustrada en la figura 2.5.Los
campos descritos en la figura 2.5 se describen a continuacin:
a. Eersi"n, nos indica el nmero de la versin del protocolo de
internet (P), es decir, que para Pv4 el valor ser 4.

b. Longitud de encabeFado <I7L3 Internet Header Length=,
describe la longitud del encabezado en nmero de grupos de 32
bits cada uno de 4 bits.

c. +ipo de ser$icio, nos permite saber la importancia de los datos
enviados, condicionando la forma en que sern tratados en la
transmisin de 8 bits.

d. Longitud tota, nos indica la longitud completa en bytes del
datagrama de 16 bits, incluyendo el encabezado y los datos. En la
prctica el datagrama es pequeo (16 bits) y tericamente no ser
mayor a 65.535 bytes.

e. Identi0icaci"n, utilizada para el ensamble de los fragmentos de un
datagrama de 16 bits.

f. /anderas, es un indicador empleado en la fragmentacin de 3 bits.

g. 1ragmentaci"n, permite ensamblar los datagramas previamente
fragmentados, cuyo valor es de 64 bits (grupos de 8 bytes),
inicializado en 0 para fragmento 1 de 16 bits.

h. Lmite de e8istencia <++L3 Time to Live=, es aquel nmero
disminuido cada vez que el paquete de datos (8 bits) pasa por un
nodo de red, si el valor toma un 0 indica que el paquete se
descarta. Por cuestiones de seguridad debemos evadir la

29

redundancia cclica, empleado por razones de seguridad siendo
improbable que esto ocurra en una red bien diseada.

i. 'rotocoo, es un nmero que se emplea para definir el protocolo
perteneciente al datagrama (8 bits), de tal manera que sea tratado
eficientemente cuando llegue a su destino.

j. Comprobaci"n, permite verificar los datos que contienen al
encabezado del P sean correctos, dicha eficiencia no se utiliza
para evaluar los datos ya incluidos, sino que los datos de usuario
se comprueban posteriormente del encabezado siguiente,
correspondiente al nivel de capa de transporte (16 bits).
Adicionalmente, si cambiamos la opcin de encabezado, dicho
campo ser calculado nuevamente.

k. Direcci"n 0uente, es aquella que contiene la direccin del usuario
en la que enva el paquete de datos de 32 bits.

l. Direcci"n destino, es aquella direccin del usuario que recibe la
informacin, es decir, que los routers o gateways (medios
intermedios) conocen la direccin para llegar correctamente el
paquete de datos de 32 bits.

&.4. 'robemas con e protocoo de internet 4 <I'$4=
Como sabemos Pv4, es la cuarta versin del protocolo P y
dominante en nternet, que permite interconectar redes de manera interna
y externa. Las principales caractersticas son:
a. Enrutamiento # direccionamiento! Proporciona nicamente una
direccin a cada uno de los dispositivos de redes de paquetes. Es
decir, que Pv4 fue principalmente diseado para proveer el
enrutamiento de informacin (paquetes) mediante redes de diversa
complejidad.

0

b. Encapsuaci"n! es una divisin antigua de TCP *%ransmission
&ontrol 'rotocol+, localizado en la capa 3 del modelo SO/OS y
funciona sobre diversos protocolos de nivel inferior.

c. *e6or es0uerFo! El protocolo P provee un servicio de transmisin
de paquetes no fiable(o de mejor esfuerzo). No se asegura que los
paquetes enviados lleguen correctamente al destino.

Pv4 utiliza un sistema de direcciones de 32 bits
(2
32
= 4.294.967.296)subdivididas en cinco clases que fueron descritas en
acpites anteriores. Con una simple revisin del crecimiento de
NTERNET en los ltimos 5 aos, podemos observar que las direcciones
a este ritmo se agotarn sobre los aos 2012/2013 (ver tabla 2.1).

La versin de Pv4 usada actualmente en nternet no ha cambiado
sustancialmente desde su publicacin inicial en 1981. Pv4 ha demostrado
ser un protocolo robusto, fcil de implementar y con la capacidad de
operar sobre diversos protocolos de capa 2. Si bien fue diseado
inicialmente para interconectar unos pocos computadores en redes
simples, ha sido capaz de soportar el explosivo crecimiento de
internet.(Palet, 2007)

En aquel momento tanto el nmero de ordenadores conectados
como las expectativas de crecimiento eran mucho ms moderados de lo
que han sido realmente, y por tanto la suposicin de que un tamao de 32
bits sera suficiente pareca razonable. De esta manera, podemos
justificar la revisin de la versin 4 del protocolo P desde dos puntos de
vista principalmente:
1. +9cnico! Donde el direccionamiento es insuficiente, debido a la gran
demanda y que a futuro incrementa considerablemente. Las tablas
de encaminamiento o de direcciones, son las encargadas de
almacenar los routers internamente, y empleados para saber hacia
dnde deben encaminar un datagrama, son excesivamente grandes
debido a la enorme cantidad de direcciones que existen actualmente

1

y al sistema de encaminamiento utilizado, lo que obligara a los
routers a mantener grandes cantidades de direcciones para conocer
hacia dnde deben redireccionar los datagramas.

2. ,ocia! Las necesidades de los usuarios de NTERNET han
aumentado espectacularmente, exigiendo nuevas capacidades
(seguridad, privacidad, comercio electrnico, velocidad...) que la
versin 4 no puede proporcionar.

&.%. 7istoria de 'rotocoo de Internet $ersi"n (.
La historia de pv6 se inici en el ao 1990, cuando se revel que las
direcciones Pv4disponibles estaban disminuyendo aceleradamente.
Segn estudios realizados por profesionales que indicaban que las Pv4
se agotaran alrededor del 2005. Dichos estudios fueron muy
cuestionados por toda la comunidad de nternet, y es de ah que iniciaron
la bsqueda de posibles soluciones. Para ese entonces se plantearon dos
soluciones:(Dunmore, 2005)
1. Mnimo: Salvaguardar el protocoloPv4, es decir, mantenerlo
intacto, slo se debe aumentarla longitud de la direccin. Esto es
muy sencillo, lo que ocurrira es tener menos suplicio en la fase de
despliegue.
2. Mximo: Desplegar completamente la nueva versin del protocolo
Pv6, cuyo enfoque permitira incorporar nuevas caractersticas y
mejoras en Pv4.

Debido a que no exista tanta urgencia en plantear una solucin
rpida, el desarrollo de un nuevo protocolo fue elegido, es decir, que el
nombre original fue Png (Prxima generacin P, P .e0t Eeneration)
mismo que fue desplazado por Pv6, siendo este el nombre definitivo,
llevados de la mano por Steven Deering y Robert Hinden.
El primer conjunto de protocolos RFCs que rigen al Pv6, fue
presentado finalizando el ao 1995, dicho protocolo se lo denomino RFC
1883: Protocolo de nternet versin 6 (Pv6). Una vez que se tena

2

disponible el RFC 1883 las implementaciones fueron esperadas con
entusiasmo, pero nunca ocurrieron.

Para ese entonces (dcada del ao 1990) el auge significativo de
nternet en empresas causo incertidumbre entre ellas, donde tenan que
resolver un complicado problema de negocio, invertir en Pv6 que traera
algunos beneficios a futuro, o invertir en el despliegue de Pv4, ya que
cualquiera de los dos protocolos (Pv6 e Pv4) les representaran
ganancias. Finalmente la mayora de las empresas decidieron escoger el
retorno rpido y fcil de las inversiones y desarrollaron productos basados
en Pv4.

Surgieron otros mtodos para mantener el espacio de direcciones, el
ms importante es el enrutamiento sin clase entre dominios (CDR,
Classless nter-Domain Routing), como consecuencia, los sitios recin
conectados obtuvieron significativamente menos direcciones que en aos
anteriores. El uso del CDR retraso la implementacin de Pv6 ante los
ojos de muchas personas, pero no en todos.

Aquellos sitios nuevos o en expansin desarrollaron mtodos para
limitar este recurso, uno de estos enfoques ha sido la traduccin de
direccin de red (NAT, Network Address Translation) que permiti utilizar
a las redes de computadoras un nmero cualquiera de direcciones
privadas, y para luego convertirlas en pblicas cuando los paquetes
dejaran el sitio y viceversa. NAT utiliza el mecanismo de compartir
direcciones pblicas a travs de hosts, as como otros mecanismos tales
como PPP (Point to Point Protocol) y DHCP (D$namic Host &onfi!-ration
'rotocol) proporcionan un medio para que hosts alquilen direcciones por
un cierto perodo de tiempo.

&.(. 'rotocoo de internet $ersi"n ( <I'$(=
El Protocolo de nternet versin 6 (Pv6) ha sido definido por el RFC-
2460, cuyo diseo ha sido para sustituir alPv4 (RFC 791), en la

actualidad se estn incorporando en la gran mayora de dispositivos
electrnicos que acceden a nternet tales como: placas de red,
switches, routers y todo dispositivo de conectividad.

Steve Deering de Xerox PARC y Craig Mudge fueron los que
crearon y disearon el protocolo de internet Pv6 destinado a sustituir a
Pv4, cuyo lmite en el nmero de direcciones de red admisibles est
empezando a restringir e impedir el crecimiento de nternet y su uso
en pases de gran densidad de poblacin como: China, ndia, y otros
pases Asiticos, en Ecuador hay aproximadamente 7 millones de
usuarios a junio 2012.

Dicha versin (Pv6) mejorar el servicio globalmente; por ejemplo,
proporcionar a futuras celdas telefnicas y dispositivos mviles sus
direcciones propias y permanentes, esto no sera poca cosa. A inicios del
2010 se tena al menos 10% de P's disponibles. Es por esto que la ANA
(Agencia nternacional de Asignacin de Nmeros de nternet, por sus
siglas en ingls) entreg en febrero 2011 el ltimo bloque de direcciones
disponibles (33 millones) a la organizacin encargada de asignar P's en
Asia, un mercado que est en auge y no tardar en consumirlas todas,
por lo que hemos mencionado anteriormente, su gran crecimiento en
poblacin.

Esta nueva revisin del protocolo P se numerar con la versin 6 y
no versin 5 para evitar confusiones, ya que anteriormente se hicieron
pruebas aadiendo extensiones a la versin 4. Dichas extensiones
experimentales no terminaron de formalizarse con una nueva versin del
protocolo, por esto fue preferible evitar posibles conflictos de numeracin,
razn por la cual el nmero de versin es 6.

Bajo estas circunstancias, Pv6 conocido tambin como Png (P de
prxima generacin) ofrece mayor flexibilidad y eficacia para dar
soluciones a una amplia gama de nuevos problemas. Los principales
objetivos que sigue Pv6 son:

4

a) Admitir miles de millones de equipos, superando las limitaciones de
espacio para las direcciones Pv4 actuales;
b) Reducir el tamao de las tablas de enrutamiento;
c) Simplificar el protocolo para permitir que los routers enruten
datagramas de manera ms rpida;
d) Brindar mejor seguridad (autenticacin y confidencialidad) que la
proporcionada por el protocolo P actual;
e) Prestar ms atencin al tipo de servicio y, particularmente, a los
servicios asociados con el trfico en tiempo real;
f) Facilitar la difusin a destinos mltiples, permitiendo especificar el
tamao;
g) Permitir la movilidad de un equipo sin cambiar su direccin;
h) Permitir el futuro desarrollo del protocolo;
i) Posibilitar la coexistencia pacfica del protocolo antiguo con el nuevo.

&.(.1. Caractersticas de I'$(.
El protocolo de internet versin (Pv6) conserva muchas de las
caractersticas que hicieron exitoso a Pv4, dentro de las cuales se puede
destacar que opera sin conexiones, es decir, que cada datagrama tiene
una direccin de destino y su enrutamiento es independiente. Tambin
resaltamos que como Pv4, la cabecera de cada datagrama tiene una
cantidad mxima de saltos que deben de hacerse antes de descartarlo.
Sin embargo existen otras caractersticas que adems de ser
conservadas, y que Pv6 tambin se encarga de mejorarlas. (Pinillos,
2003)

Existen caractersticas muy interesantes que Pv6 trae consigo, ya
que resuelven muchos de los problemas de la versin 4. Las
caractersticas ms importantes de Pv6 se describen a continuacin:
(Pinillos, 2003)

a. Direccionamiento. (Pinillos, 2003)
El campo para direccionar o identificar dispositivos es de 128 bits
(2128), este campo es lo suficientemente grande para manejar el

5

crecimiento continuo de nternet mundial durante muchas dcadas. El
nmero de direcciones P que ofrece Pv6 es alrededor de 340
sextillones.
3

b. Rendimiento
Actualmente, las redes LAN y WAN estn progresando respecto a la
velocidad de transmisin, pudiendo utilizar velocidades de ciento de
Megabits por segundo con la tendencia de llegar a varios Gbps (Gigabits
por segundo). Esto se debe a que la tecnologa mejora da a da y la
existencia de la necesidad de ancho de banda por parte de nuevos
servicios y aplicaciones, en especial las basadas en grficos.(Pinillos,
2003)

Por esta razn, los ro-ters deben tener la capacidad de reenviar los
datagramas P de manera rpida y as afrontar velocidades inmensas y el
incremento de carga lo ms rpido y eficiente posible. Para esto es
necesario plataformas de hardware robustas, as como tambin es
importante el diseo P que se tenga. El protocolo de internet versin 6
(Pv6) ofrece tres aspectos de diseo que contribuyen a mejorar el
rendimiento de las interredes:
La simplificacin de la cabecera P. Se reducen los trece campos
presentes en Pv4 a slo ocho campos. Esto permite a los ro-ters
procesar con mayor rapidez los paquetes y mejorar el rendimiento.
(Lzaro & Miralles, 2004)

Mayor eficiencia en el uso de los campos en la cabecera del
paquete. Este cambio fue esencial, ya que algunos capos que
antes eran obligatorios ahora son opcionales. Adems, la
representacin de las opciones es diferente, haciendo ms sencillo
que los routers hagan caso omiso de opciones no dirigidas a ellos,
mejorando as el tiempo de procesamiento de paquetes. (Lzaro &
Miralles, 2004)

Recuperado el 12 !unio 2012 online http://www.ip"6.e#/e#$%&/'a(#/)agina#/tecnica#.a#p*

6

La cabecera del paquete Pv6 es de longitud fija mientras que la
cabecera de Pv4 es de longitud variable, simplificando una vez
ms el proceso.(Lzaro & Miralles, 2004)

La fragmentacin no se permite en lo routers Pv6. Solo puede ser
realizada por el origen.(Lzaro & Miralles, 2004)

c. ,er$icios de red! (Pinillos, 2003)
Pv6, cuenta con un mecanismo que permite a un transmisor y un
receptor establecer una trayectoria de alta calidad por la red y asociarle
los datagramas, garantizando el alto desempeo a aplicaciones de audio
y video en tiempo real. Pv6 permite el etiquetado de los paquetes que
pertenecen a un flujo de trfico en particular para la cual el origen solicita
un manejo especial.

d. Capacidad de seguridad! (Pinillos, 2003)
Pv6 proporciona soporte nativo para seguridad basndose en sus
cabeceras de extensin. Por medio de las cabeceras de autenticacin y la
cabecera de encapsulamiento seguro, se logra proveer diferentes niveles
de seguridad para diferentes usuarios. Esto es muy importante ya que
diferentes comunidades de usuarios tienen diferentes necesidades de
seguridad.

e. Caidad de ser$icio! (Pinillos, 2003)
La calidad de servicio en Pv6, es un servicio ms robusto que el
provisto por datagrama llamados, Prioridad (Hpriorit$ =4 bitsGK) y Etiqueta
de Flujo (HLloB /abel =24 bitsGK). Estos, son usados para que un host
pueda identificar los paquetes, para el cual se requiere un manejo
especial por parte de los routers Pv6. Esta capacidad es importante, para
el momento de soportar aplicaciones que requieren el menor grado de
retardos, dela$ o alteraciones en el flujo. Estos tipos de aplicaciones son
comnmente descritas como aplicaciones multimedia o de tiempo real.

7

&.(.&. ArHuitectura de 'rotocoo de Internet $ersi"n ( <I'$(=
La arquitectura de Pv6 es una versin mejorada de Pv4, sin
modificar demasiado la estructura ni contenido, pero con cambios
sustanciales en seguridad y retirando datos innecesarios o redundantes,
dichos cambios se debieron a 20 aos de experiencia con Pv4. La
arquitectura Pv6 est conformada por una cabecera de 40 bytes fijos,
una cabecera de extensin opcional que no es adicionada a la cabecera
fija sino que se agrega a la carga til en caso sea utilizada, tal como se
observan en la Figura 2.7.

La nueva estructura de la cabecera del protocolo P versin 6 se
caracteriza principalmente por dos particularidades:
1. Ampliar el campo de direccin P, es decir, de 32 bits se aumenta a
128 bits cada direccin.
2. Utilizar campos de longitud fija, facilitando as el proceso de cada
datagrama en los ruteadores.

Figura 2. 7:Datagrama del Pv6.
Fuente: http://www.imaginar.org/mdi/docs/ipv6.pdf

Como se indic anteriormente Pv6 tiene una cabecera del doble de
la cabecera Pv4, esto debido al tamao de los campos "Direccin de

8

origen y "Direccin de destino. La cabecera posee los siguientes
campos:
a. Eersi"n, indica el nmero de la versin del protocolo de internet
(P), es decir, que para Pv6 el valor ser 6.

b. Longitud de carga Dti (Payload Length=, describe la longitud de
los propios datos, llegando hasta 65.536 bytes, cuya longitud es de
16 bits, sea, 2 bytes.

c. Cabecera siguiente (next header), emplea sucesivas cabeceras
encadenadas, de ah que desapareci el campo de opciones, cuya
longitud es de 8 bits (1 byte).

d. Lmite de ,atos (hop limit), cuya longitud es de 8 bits (1 byte).

e. Case de trI0ico (traffic class), conocido tambin como prioridad
(priority) o clase (class), considerado como equivalente al TOS de
Pv4, su longitud es de 8 bits (1 byte).

f. EtiHueta de 0u6o (flo la!el), permite soportar trficos con
requisitos de tiempo real, cuya longitud es de 20 bits.

g. Direcci"n de origen, contiene la direccin del usuario en la que
enva el paquete de datos de 128 bits.

h. Direcci"n de destino, recibe toda la informacin, es decir, que los
routers o gateways conocen la direccin para llegar correctamente
el paquete de datos de 128 bits.

A continuacin en la figura 2.8, se muestra el uso de conceptos de
cabeceras de extensin, definidas en el campo siguiente cabecera, cuyo
mecanismo en cada cabecera es "encadenada a la siguiente y anterior
en caso de existir:

9

Figura 2. 8: Extensiones de cabeceras de Pv6.
Fuente: http://www.naguissa.com/universidad/wiki-td/ApuntsTema5.html

En la figura 2.9 se pueden apreciar los cambios de la cabecera Pv6
respecto a la cabecera Pv4, donde vemos que la versin no ha cambiado
y esto se mantendr porque durante un buen tiempo convivirn los dos
protocolos. Otros campos fueron eliminados, tales como, tamao de
encabezado, tipo de servicio, nmero de identificacin del datagrama,
banderas, nmero de byte del datagrama fragmentado y el checksum se
eliminaron, mientras que se refinaron otros campos como longitud del
datagrama, tiempo de vida y tipo de protocolo.

Figura 2. 9: Formato del datagrama Pv4 vs Pv6.
Fuente:
http://rodrigoaguilera.net/sites/rodrigoaguilera.net/files/miscelanea/ipv6.pdf

40

En la tabla 2.4 se muestran las asignaciones de nmero y
abreviatura para que el switch o ruteador reconozca cada tipo de
encabezado. Los datagramas en teora pueden tener ms de un
encabezado, que por lo general no deberan tener problemas con los
ruteadores, que son los encargados de procesar cada encabezado a
medida de que lean al datagrama, pero sin embargo, hay otros
encabezados de importancia como el encabezado de autenticacin que
rechaza al datagrama completamente.
Tabla 2. 4: Valores asignados para encabezados en Pv6.
Eaor
decima
Abre$iatura
<@e#Jord=
Descripci"n
. HBH Opciones entre saltos
4 P P e P (encapsulacin en Pv4)
% ST Stream
( TCP Transmition Control Protocol
1B UDP User Datagram Protocol
%1 AH Authentication Header
%& ESP Encrypted Security Payload
%- NULL No Next Header
(. DO Destination Options Header
1-4 JBGR Jumbogram
Fuente: (Gordo Saez, 1998)

Como lo indica (Verdejo Alvarez, 2000) el orden de los encabezados
dependiendo de su importancia son los siguientes:
a) Encabezado P versin 6 (Pv6 Header).
b) Encabezado de opciones entre saltos (Hop-by-hop Options Header).
c) Primer encabezado de opciones de destino (Destination Options
Header).
d) Encabezado de enrutamiento (Routing Header).
e) Encabezado de fragmentacin (Fragment Header).
f) Encabezado de autenticacin (Authentication Header).
g) Segundo encabezado de opciones de destino (Destination Options
Header).

41

h) Encabezado de protocolo de nivel superior (TCP, UDP).

&.(.3. 1ormato de direcciones I'$(.
La arquitectura del formato de direcciones Pv6 se encuentra
descrita en RFC4291. Las direcciones Pv6 estn compuestas por 8
campos de 16 bytes = 128 bits de largo, agrupados los bytes de 2 en 2 y
separados por dos puntos ":, cuya representacin es en hexadecimales
(0-F), tal como se muestra en la figura 2.10.

Figura 2. 10: Formato de direcciones Pv6.
Fuente:http://rodrigoaguilera.net/sites/rodrigoaguilera.net/files/miscelanea/ipv6.pd
f

Tambin se pueden simplificar el formato de direcciones Pv6 por
nica vez, dicha simplificacin est representada por " para uno o varios
grupos de 2 bytes a 0, tal como se muestra en la figura 2.11.

Figura 2. 11: Formato simplificado de direcciones Pv6.
f

En la figura 2.12 se muestran los 3 campos que dividen el formato
de direcciones Pv6, que son el:

Figura 2. 12: Campos que conforman las direcciones Pv6.
f

42

a) 're0i6o de red3 conjunto de direcciones asignadas a una
organizacin, en las SPs cuentan con prefijos de 32 bits, mientras
que las organizaciones tienen 48 bits. (ver figura 2.13)

Figura 2. 13: Prefijos de red de 32 y 48 bits.
f

b= Identi0icador de subred3 se encarga de identificar una subred
dentro de una organizacin.

c= Identi0icador de mIHuina3 permite identificar una interfaz de una
mquina dentro de una subred.

&.(.4. Direccionamiento I' $(.
Como se ha explicado con anterioridad el cambio de Pv4 a Pv6 es
la falta de direcciones Pv4, es decir, que Pv6 ha hecho un esfuerzo
grande para que no vuelva a pasar lo mismo, al pasar direcciones de 32
bits a 128 bits. El direccionamiento Pv6 sirve para identificar interfaces de
redes (individual o grupos de interfaces) de 128 bits de longitud, por lo
tanto, a una interface de nodo se le asignan varias o mltiples direcciones
Pv6. Por este motivo Pv6 las clasifica en tres tipos de direcciones:
Unicast, Anycast y Multicast.

&.(.4.1. 2nicast
Es un identificador para una nica interfaz, es decir, que el paquete
enviado a una direccin -nicast se entrega solamente a la interfaz
identificada con la direccin mencionada, sin ser encaminados por ningn
router.Se configuran automticamente, tal como muestra la figura 2.14.

4

Figura 2. 14:Direccionamiento (Unicast)local de enlace.
f

Para direcciones locales de enlace en Ethernet, se construye un
identificador de interfaces utilizando las direcciones MAC de una tarjeta
Ethernet, tal como muestra la figura 2.15.

Figura 2. 15: Direccionamiento (Unicast) local de enlace en Ethernet.
f

En la figura 2.16 se puede apreciar la aplicacin de direccionamiento
unicast, en la que el equipo transmite uno o varios paquetes a un nico
destino.

Figura 2. 16: Direccionamiento Unicast.
Fuente: http://blog.capaocho.net/2009/12/introduccion-al-multicast-parte-i.html

44

En este caso, Pv6 introduce el uso de contextos en las direcciones
unicast, los mismo que definen el dominio lgico o fsico de una red. De
tal manera, reconocerel contexto al que corresponde una determinada
direccin permitiendo realizar un manejo ptimo de los recursos de la red,
as optimizando su desempeo.(Jara, 2009)

Existen varios tipos de direcciones Pv6 6nicast que pueden
pertenecer a uno de los tres contextos existentes: /in9G/ocal (Local de
enlace)M 6niI-eG/ocal (Locales nicas)M $ Elobal 6nicast (Globales).
Lin"#Local: Estas direcciones identifican interfaces en un mismo
enlace. (Capa 2)
4

$ni%&e#Local: Son direcciones que identifican interfaces en un
mismo sitio o rea topolgica compuesta por varios enlaces o
dominios de la capa 2.
5

'lo!al $nicast: Son direcciones que identifica interfaces en toda
la nternet.
6

La figura 2.17 nos muestra la estructura jerrquica de los contextos
6nicast. En donde el contexto global es el ms grande y comprende los
dos contextos restantes.

Figura 2. 17: Contextos de direcciones Unicast.
Fuente: http://www.uji.es/bin/docs/projectes/ipv6/ipv6p.pdf

Es importante recalcar que en Pv6 una interfaz puede tener ms de una
direccin P.

4
Recuperado el 12 Junio 2012 online http://www.uji.es/bin/docs/projectes/ipv6/ipv6p.pdf
5
6

45

&.(.4.&. An#cast
Es un identificador de mltiples interfaces (generalmente diferentes
nodos), donde los paquetes destinados a una direccin an$cast se
entregan a una sola interfaz, por lo general, la ms cercana dentro del
grupo de direcciones an$cast. Ahora, si la direccin multicast define la
comunicacin <<uno>> a <<muchos>>, una direccin an$cast se definira
como <<uno>> a <<uno-entre-muchos>>.

Por ejemplo, permite crear mbitos de redundancia, de tal manera
que varias computadoras pueden ocuparse del mismo trfico de acuerdo
a la secuencia determinada por el router, siempre que la primera caiga.
Las an$cast no tienen un espacio propio dentro del direccionamiento Pv6,
utilizan el mismo espacio que las direcciones unicast, es decir, si en todas
las mquinas a las que se quiere asignar la direccin an$cast se
encuentran en la misma organizacin, la direccin an$cast tendr el
mismo prefijo que las direcciones -nicast de ese sitio, tal como se ilustra
en la figura 2.18.

Figura 2. 18: Direccionamiento (Anycast) de los routers.
f

Para el caso de los routers que pueden soportar direcciones para
subredes que se encuentren conectadas (ver figura 2.19). La utilidad de
las direcciones an$cast sirven para implementar mecanismos, tales como:
Comunicacin con el servidor ms cercano, donde las direcciones
permiten a los usuarios comunicarse con unico servidor
seleccionado por la red y que sea el ms cercano.
Descubrimiento de servicios, es decir, que si configuramos un nodo
con Pv6 no hay necesidad de especificar la direccin del servidor
DNS, Proxy, etc..
Movilidad, son aquellos nodos que se comunican mediante un
router de los disponibles en la red.

46

Figura 2. 19: Direccionamiento Anycast.
Fuente:http://blog.capaocho.net/2009/12/introduccion-al-multicast-parte-i.html

&.(.4.3. *uticast
Es un identificador para mltiples interfaces, es decir, que un
paquete se envia a una direccin multicast, se entrega a todas las
interfaces identificadas por dicha direccin, muy utilizadas para
aplicaciones de retransmisin mltiple (broadcast). El direccionamiento
m-lticast pertenece a uno o varios grupos, cuyo formato es el mostrado
por la figura 2.20.

Figura 2. 20: Direccionamiento (Multicast) para retransmisin mltiple.
f

En Pv6 se requiere que todos los nodos soporten m-lticastC ya que
el nuevo protocolo ofrece muchas funcionalidades que usan este tipo de
direcciones.(Regis dos Santos, Moreiras, Reis, & Soares da Rocha, 2010)

47

De la figura 2.20, los primeros 8 bits significa que es una direccin
multicast; para los siguientes 4 bits, el bit "T indica que si T=0 se trata de
una direccin permanente y si T=1 nos indica que hay una direccin
temporal. En la tabla 2.5 se describe el significado de cada uno de los bits
de mbito. Para el identificador de grupo, permite identificar al grupo
multicast referido, ya sea de manera permanente o temporal, dentro de un
determinado mbito.

Las direcciones m-lticast envan un nico paquete a varios host, por
lo tanto podemos decir que cumplen una funcin similar a la de broadcast,
sin embargo, se diferencian solo porque en el caso de las direcciones
m-lticast un grupo de @osts reciben el paquete, mientras que en las de
broadcast el paquete se enva a todos los @osts de la red sin excepcin.
(Regis dos Santos, Moreiras, Reis, & Soares da Rocha, 2010)

Esta clase de direcciones no deben ser empleadas como direccin
de origen de un paquete. Las direcciones m-lticast proceden del bloque
FF00::/8, donde el prefijo FF, que identifica una direccin m-lticast, es
precedido por cuatro bits, los mismos que representan cuatro fla!s, y un
valor de cuatro bits que definen el alcance del grupo m-lticast. Los 112
bits restantes se utilizan para identificar el grupo m-lticast.(Regis dos
Santos, Moreiras, Reis, & Soares da Rocha, 2010)

Figura 2. 21: Direccionamiento Multicast.
Fuente:http://blog.capaocho.net/2009/12/introduccion-al-multicast-parte-i.html

48

En la figura 2.21 se puede apreciar la aplicacin del
direccionamiento multicast. Si la asignacin de direcciones multicast es de
manera permanente, el identificador de grupo 101 (en el sistema
hexadecimal) hacia el grupo de servidores de tiempo (NTS), entonces:
FF01::101, todos los NTS en el mismo nodo que el paquete
original.
FF02::101, todos los NTS en el mismo enlace que el paquete
original.
FF05::101, todos los NTS en el mismo sitio que el paquete original.
FF0E::101, todos los NTS en internet.
Tabla 2. 5:Significado de los bits de mbito.
Eaor
7e8adecima
Descripci"n
. Reservado
1 mbito Local de Nodo
& mbito Local de Enlace
3 No asignado
4 No asignado
% mbito Local de Sitio
( No asignado
B No asignado
) mbito Local de Organizacin
- Jumbogram
A No asignado
/ No asignado
C No asignado
D No asignado
E mbito Global
1 Reservado
Fuente: www.6bone.net

Ahora para el caso de direccin multicast de nodo solicitado, se
debe asociar entre las direcciones capa 2 (MAC) y direcciones Pv6,
conocido como direccin "multicast de nodo solicitado. La mencionada

49

direccin contiene parte de la direccinPv6 que deseamos consultar,
cuya estructura descrita se asemeja a la figura 2.21.

Un nodo que se configura con direcciones Pv6, permite unirse de
manera automtica al multicast (grupo)de acuerdo a la direccin de nodo
solicitado. Puesto que dicha direccin toma solamente los 24 bits ltimos
de la direccin Pv6.En la Tabla 2.6se describen algunas direcciones Pv6
y sus correspondientesdirecciones multicast de nodo solicitado.
Tabla 2. 6:Esquema de direcciones multicast de nodo solicitado
Direcci"n I'$( soicitado
Direcci"n muticast de
nodo
&)..!&B.!bcd.!3!!1 ff02::1:ff00:1
&)..!&B.!!1&3.!1...!a34!-e-a ff02::1:ff34:9e9a
&)..!&B.!!34de!&...!a34!-e-a ff02::1:ff34:9e9a
0c..!.!.!1!!aaaa!a1 ff02::1::ffaa:a1
Fuente: www.6bone.net

&.B. +raductores de direcciones de red <NA+= en I'$(.
Para las NAT es necesario recordar la nomenclatura establecida por
la Empresa CSCO, la misma que diferencia entre direcciones P
manejadas internamente en una red y de las que acceden al internet, en
otras palabras, se refieren al intranet (direcciones locales) e internet
(direcciones globales). Para el caso de las direcciones locales como se
vio anteriormente son nicas para cada empresa, aunque esto no impide
que otra empresa tengan las mismas direcciones sin ocasionar conflictos
en nternet; mientras que las direcciones globales son nicas en la
nternet.

Actualmente en muchas empresas ecuatorianas que emplean como
red bac9bone de nternet estn teniendo problemas, afectando as a los
usuarios finales, todo esto ocurra con direccionamiento Pv4, es decir,
que la empresa no poda resumir sus direcciones porque las tablas de
ruteo se expandan demasiado. Si una empresa no puede acceder a

50

direcciones globales en la nternet, evidentemente se ve obligada a
generar direcciones locales para uso interno de la red (intranet de la
empresa).

51

Captuo 3! 'ropuesta de *ecanismo de +ransici"n a I'$(

En el presente captulo se describen los mecanismos de transicin
que permiten operar redes cuyas direcciones pertenecen a los protocolos
versin 4 (Pv4) y versin 6 (Pv6), dichos mecanismos deben ser
implementados por las operadoras del servicio de internet (SP) debido a
la poca disponibilidad de direcciones Pv4. A travs de la
Superintendencia de Telecomunicaciones (SUPERTEL) y conjuntamente
con Ministerio de Telecomunicaciones (MNTEL) se regular y controlar
el cumplimiento de adoptar los mecanismos necesarios para la transicin
temporal y que a futuro con llevar a una migracin total a Pv6.

3.1. La transici"n de I'$4 a I'$(
Los mecanismos para realizar la transicin del protocolo de internet
versin 4 (Pv4) al de versin 6 (Pv6) no son tan fciles como aparentan y
peor an llevar a una migracin total a Pv6, por eso es recomendable
ejecutar una transicin en forma gradual mientras coexistan los protocolos
actuales Pv4 e Pv6, debido a que ms adelante cambiaran de
direcciones de 32 a 128 bits, sin necesidad de suspender servicios.

Los mecanismos de transicin de Pv4 a Pv6 que se describirn
para la ejecucin por parte de las operadoras o proveedoras del servicio
de internet, denominadas SP, no sern posibles de realizar sino
adquieren equipos robustos y algunas aplicaciones, que muchas veces
dependen de la capacidad de procesamiento de paquetes generados por
los dos protocolos Pv4 e Pv6. Dicho proceso de ejecucin del
mecanismo que junto a los nombres de dominio del sistema (por sus
siglas en ingles DNS, Domain Name System) permiten traspasar los
dominios actuales para direcciones de 128 bits.

En pases desarrollados como los del continente europeo se han
evaluado ciertos mecanismos para la coexistencia entre ambos
protocolos, lo que permitir ac en el Ecuador una migracin progresiva

52

de las redes as como los equipos de usuarios. Existen tres mecanismos
de transicin:
a. Dual Stack.
b. Tneles.
c. Traduccin.

Cada una de las empresas proveedoras (SPs) tienen la mayora de
clientes o usuarios, mismos que necesitan una conectividad para acceder
a cuentas de correo electrnico (e-mail), bases de datos y aplicaciones
para servidores locales, para algunos lo ideal sera en ejecutar la
migracin, pero para la mayora de entendidos en el tema lo ideal en la
actualidad es la transicin para grupos de trabajo denominados islas y
departamentos de redes de computadoras en Ecuador, y a futuro una
migracin total a medida que los usuarios vayan incrementndose e
incluyendo equipos que soporten el protocolo de internet versin 6 (Pv6).

En este contexto de migracin a Pv6, surgen nuevos trminos con
los cuales se designa a ciertos tipos de nodos, los cuales son:

a. Nodo I'$4 Dnicamente, el cual puede ser un host o un
enrutador que implementen nicamente Pv4.

b. Nodo I'$(;I'$4, el cual es un host o enrutador que implementan
los dos protocolos Pv4 e Pv6.

c. Nodo I'$( Dnicamente, el cual puede ser un host o un
enrutador que implemente nicamente Pv6.

d. Nodo I'$(, el cual puede ser un host o enrutador que
implemente Pv6. Los nodos Pv6/Pv4 y nodos Pv6 nicamente
son nodos Pv6.

5

e. Nodo I'$4, el cual puede ser un host o enrutador que
implemente Pv4. Los nodos Pv6/Pv4 y nodos Pv4 nicamente
son nodos Pv4.

3.&. +ipos de mecanismos de intercone8i"n de I'$4 a I'$(
Ms all de los mecanismos que se utilicen para ser implementados
por hosts y routers Pv6, cuya clave de xito es que deben ser
compatibles con Pv4, agilitando la expansin de Pv6 en el nternet, lo
que facilita as la transicin. Dichos mecanismos son diseados para ser
ejecutados por hosts y routers Pv6 que requieran interactuar con hosts
Pv4 y empleen la infraestructura de enrutamiento Pv4.

3.&.1. Dua I' La#er
Conocido tambin como doble capa P la cual permite proveer hosts
y routers el soporte completo para ambos protocolos Pv4 e Pv6, es decir,
que un dispositivo con ambas pilas pueden recibir y enviar trfico a nodos
que soportan uno de los dos protocolos, como se ilustra en la figura 3.1.
Se puede configurar de forma manual cuando el usuario conoce la
direccin Pv6 del nodo destino.

Figura 3. 1: Esquema del mecanismo Dual P Layer.
Fuente: http://www.redesymas.org/2011/06/mecanismos-de-transicion-
basicos-ipv4.html

54

Una pila habilitada tiene una direccin P asignada, donde el nodo
Pv6/Pv4 puede operar de tres modos distintos:
a. Con la pila Pv4 habilitada pero la pila Pv6 deshabilitada
b. Con la pila Pv6 habilitada pero la pila Pv4 deshabilitada
c. Con las dos pilas habilitadas

Esto es debido a que los nodos soportan tanto Pv4 como Pv6, los
mismos que adquieren direcciones con mtodos propios, por ejemplo para
obtener su direccin Pv4 utiliza DHCP, y el mismo nodo para obtener su
direccin Pv6 utiliza DHCPv6.

La otra configuracin es utilizando nombre de dominio
completamente configurado (FQDN) en un servidor DNS con ambas
direcciones Pv4 e Pv6. La desventaja es que hay que tener las tablas de
enrutamiento y el soporte para Pv4 e Pv6.

3.&.&. +unneing I'$( o$er I'$4.
Conocido como tneles Pv6 sobre Pv4 la cual permite encapsular
paquetes de Pv6 dentro de los encabezados (headers) de Pv4 para ser
transportados sobre estructuras de enrutamiento actuales, mediante dos
tipos de tneles los configurados y automticos. En realidad Pv6 es una
infraestructura en evolucin constante, es decir, que mientras se
desarrolla y expande Pv6 va a existir el enrutamiento actual Pv4, que
permitir transportar un trfico en Pv6, para lo cual el proceso de lograr
esto es los tneles (Tunneling) que se muestra en la figura 3.2.

55

Figura 3. 2: Esquema del mecanismo Tunneling Pv6 over Pv4.
Fuente: http://www.dynalconf.org/30-1_ipv6_ipv6_over_ipv4/index.html

Tanto hosts como routers de Pv6/Pv4 permiten enviar datagramas
Pv6 sobre regiones cuya topologa de enrutamiento sea Pv4,
encapsulndolos dentro de paquetes Pv4. Los tneles (Tunneling)
pueden ser empleados en una variedad de formas, que se describen a
continuacin:

(o&ter to (o&ter! Los routers Pv6/Pv4 interconectados con una
infraestructura Pv4 pueden pasarse entre s paquetes Pv6. En
este caso el tnel abarca un segmento del trayecto que toma el
paquete Pv6 tal como se muestra en la figura 3.3.

Figura 3. 3: Esquema del mecanismo Router to Router.
Fuente: J. Coellar y J. Cedeo.

56

Host to (o&ter: Los host Pv6/Pv4 pueden pasar paquetes Pv6
por un router Pv6/Pv4 intermediario que sea alcanzable por la
infraestructura Pv4. Este tipo de tnel abarca el primer segmento
del trayecto del paquete, como se muestra en la figura 3.4.

Figura 3. 4: Esquema del mecanismo Host to Router.

Host to Host! Los hosts Pv6/Pv4 interconectados con una
infraestructura Pv4 pueden pasarse paquetes Pv6 entre s. En
este caso el tnel abarca el recorrido completo que toman los
paquetes, como se muestra en la figura 3.5.

Figura 3. 5: Esquema del mecanismo Host to Host.

(o&ter to Host! Los routers Pv6/Pv4 pueden pasar paquetes
Pv6 hasta su hostPv6/Pv4 destinatario (final). Este tnel abarca
el ltimo segmento del recorrido, tal como se ilustra en la figura 3.6.

Figura 3. 6: Esquema del mecanismo Host to Host.

En los casos (o&ter to (o&ter y Host to (o&ter el paquete Pv6 es
pasado mediante el tnel a un router. El punto final (endpoint) para estos
tipos de tneles es emplear un router intermediario, el mismo que debe
desencapsular el paquete Pv6 y reenviarlo a su destino final. Si enviamos
paquetes de datos a un router, el endpoint del tnel es diferente del
destino final del paquete que se ha enviado.

57

Para los dos ltimos casos Host to Host y (o&ter to Host, el
endpoint del tnel es el nodo para el cual el paquete Pv6 se ha
direccionado. Es decir, que el endpoint se determina por la direccin Pv6
de destino del paquete de datos. En consecuencia, si es una direccin
Pv6 compatible con Pv4 entonces los ltimos 32 bits describen la
direccin del nodo destino y empleado como direccin del endpoint del
tnel, por lo tanto esta tcnica se denomina t&nneling a&tomtico.

3.&.&.1. Encapsuamiento.
Para las tcnicas de encapsulacin normalmente se clasifican
dependiendo del mecanismo del nodo encapsulador para determinar la
direccin del otro extremo del tnel. Es decir, que si el extremo del tnel
resulta ser un router, ste desencapsula el paquete para posteriormente
reenviarlo a su destino final. De tal manera, que el extremo del tnel
puede no coincidir con el destino del paquete ya encapsulado.

Para el encapsulamiento de datagramas Pv6 sobre una red Pv4 se
requiere utilizar el nmero de protocolo Pv4 41.Tanto el host o router se
comportan como un nodo encapsulado y para el proceso inverso, es decir,
el desencapsulado puede ser tambin cualquiera de los dos. El
datagrama Pv6 es puesto dentro de la carga til de un datagrama Pv4,
tal y como se muestra en la figura 3.7.

Figura 3. 7: Encapsulamiento del datagrama Pv6.

58

Tanto la direccin origen y destino del datagrama ambas
pertenecientes a Pv4, son aquellas direcciones del nodo encapsulado y
desencapsulado, las misma que pueden ser o no las direcciones Pv6
origen y destino del datagrama Pv6. El proceso para el encapsulamiento
de un paquete Pv6 son:
a. El punto de entrada del tnel, es decir, el encapsulador
decrementa el campo Pv6, lmite de saltos, en una unidad,
encapsula el paquete Pv6 en la cabecera Pv4, y transmite el
paquete encapsulado a travs del tnel. Si fuera necesario el
paquete Pv4 es fragmentado.
b. El punto de salida del tnel, es decir, el
desencapsuladordesencapsula el paquete. Si el paquete fue
fragmentado, lo reensambla. Luego el punto de salida remueve
la cabecera Pv4 y procesa el paquete Pv6 a su destino original.

El mecanismo de encapsulamiento se clasifica en:
a. mbito de aplicacin: Global.
b. Requisitos de Pv4: conectividad Pv4 entre los sitios.
c. Requisitos de las direcciones Pv4: >=1 por sitio.
d. Requisitos de Pv6: ninguno.
e. Requisitos de las direcciones Pv6: los nodos finales requieren
una direccin Pv6.
f. Requisitos de mquina: pila Pv6 o doble pila.
g. Requisitos de router: doble pila.
h. mpacto del NAT: no realizar actividad en la NAT debido a que
ambos extremos del tnel deben ser enrutables, aunque puede
operar si dichos extremos se encuentran en el NAT.
i. Otros requisitos: No.

3.&.&.&. +Dne automItico.
Los tneles automticos emplean direcciones Pv6 de destino que
son compatibles con Pv4, es decir, que el paquete de datos puede ser
enviado sin inconvenientes. Ahora, si la direccin Pv6 de destino resulta

59

ser una direccin nativa, entonces el paquete no puede ser enviado
mediante el tnel automtico. Para esto es necesario las tablas de rutas
que permiten dirigir el mecanismo, es decir, tener una ruta esttica
especial como por ejemplo 0:0:0:0:0:0::/96.

Los extremos finales del tnel se determinan por el uso de las
interfaces lgicas del tnel, las rutas y las direcciones Pv6 de origen y
destino.Este tipo de direccin Pv6 es asignada exclusivamente a los
nodos que utilizan tneles automticos, mismos que permiten a los nodos
Pv6/Pv4 comunicarse por medio de la infraestructura Pv4 sin realizar la
pre configuracin del tnel. Por ejemplo, una direccin cuyo protocolo de
internet versin 4 es 10.12.83.119, cuya direccin Pv4 es compatible a la
direccin Pv6 ::10.12.83.119, donde el smbolo ':' indica que seagregaron
96 bits cuyo valor son todos ceros.

El mecanismo de tnel automtico se clasifica en:
b. Requisitos de Pv4: conectividad Pv4 entre los sitios.
c. Requisitos de las direcciones Pv4: 1 por mquina.
e. Requisitos de las direcciones Pv6: compatibilidad entre direcciones
Pv6 e Pv4.
f. Requisitos de mquina: doble pila.
g. Requisitos de router: ninguno.
h. mpacto del NAT: si atraviesa por una NAT no funcionar.
i. Otros requisitos: No.

3.&.&.3. +Dne *anua.
Los tneles manuales tambin conocidos como estticos,necesitan
ser configurados en ambos puntos finales, es decir, las direcciones origen
y destino de ambos protocolos Pv4 e Pv6, adicional a esto los nodos de
los puntos finales deben de tener doble pila. Los tneles manuales tienen
ciertos requerimientos: 1= Dos enrutadores deben de ser doble pila, &=El

60

enrutador de entrada debe de contar con una direccin Pv4 con la cual
pueda alcanzar al enrutador de salida y viceversa.

Aunque los tneles manuales tienen desventajas, para citar una, si
son varios tneles que debemos configurar, resultara pesado realizarlo,
es decir, si las direcciones P cambian para varios tneles el trabajo
tambin se convierte en pesado. Este tipo de tnel puede ser utilizado
cuando se necesitan slo pocos tneles y cuando no est presente el
NAT de Pv4.

El mecanismo de tnel manual se clasifica en:
b. Requisitos de Pv4: ninguno.
c. Requisitos de las direcciones Pv4: 1.
e. Requisitos de las direcciones Pv6: si es un cliente aislado no lo
requiere, pero si desea conectarse a una red se debe asignar un
prefijo.
f. Requisitos de mquina: doble pila y navegador Pv4.
h. mpacto del NAT: si atraviesa por una NAT no funcionar, para que
pueda operar sin inconvenientes el tnel del cliente debe estar
ubicado en el mismo ordenador que el NAT.
i. Otros requisitos: requiere de una base de datos con los tneles
actualmente en funcionamiento.

3.&.&.4. +Dne (to4.
El presente mecanismo 6to4 se configura de maneraautomtica, en
la cual los extremosdel tnel son determinados por las direcciones Pv4
(ver figura 3.8)encapsuladas dentro de direcciones Pv6 6to4. ste
pertenece al protocolo RFC 3056, para que los sitios de direcciones Pv6
se comuniquen entre s, a travs de una red de direcciones Pv4, sin
necesidad de contar con un tnel explcito.(Moore, 2001)

61

Figura 3. 8: Esquema del tnel 6to4.

A continuacin se detallan ciertas definiciones importantes:

'seudo inter0ace (to4. Es aquel punto que es equivalente a
la interface de Pv6, donde acontece el encapsulamiento 6to4
de los paquetes Pv6 dentro de paquetes Pv4.

're0i6o (to4. Es aquel prefijo diseado con las mismas
caractersticas especificadas en el protocolo RFC 3056.

Direcci"n (to4. Es aquella direccin Pv6 diseada mediante
el prefijo 6to4.

Direcci"n I'$( nati$a. Es aquella direccin Pv6 diseada
mediante cualquier otro prefijo sin provenir del 6to4.

Enrutador (to4 o de borde. Es aquel enrutador capaz de
soportar pseudo interfaces del 6to4.

7ost (to4. Es aquel host Pv6 que tiene por lo menos una
direccin 6to4.

,itio (to4. Es un sitio en el cual internamente se est
corriendo Pv6 usando direcciones 6to4.

62

Enrutador rea#. Este es un enrutador configurado para
soportar rutas con trfico de direcciones Pv6 nativa y
direcciones 6to4.

El mecanismo 6to4 se clasifica en:
b. Requisitos de Pv4: conectividad Pv4.
d. Requisitos de Pv6: prefijo 6to4 nico de forma global.
e. Requisitos de las direcciones Pv6: ninguno.
f. Requisitos de mquina: doble pila y mnimo valor de seleccin de
direcciones fuente.
g. Requisitos de router: implementar reglas de reenvo y
desencapsulacin especiales.
h. mpacto del NAT: si atraviesa por una NAT no funcionar, para que
pueda operar sin inconvenientes el router 6to4 es ubicado donde
se encuentre el NAT.
i. Otros requisitos: prefijos de tamao 48 bits.

El tnel 6to4 es un mecanismo temporal para la transicin durante el
perodo de tiempo en que coexistan los dos protocolos Pv4 e pv6, no ha
sido considerada como una solucin permanente. La direccin 6to4 est
construida en base al prefijo 6to4 2002::/16 seguido por los 32 bits de la
direccin Pv4 externa del enrutador de borde del sitio, dando como
resultado un prefijo de /48.

La figura 3.9 nos muestra dos redes 6to4 de manera independientes,
el Sitio A y el Sitio B. Cada uno de los sitios tienen configurados
enrutadores cuya conexin externa es una red Pv4. El tnel 6to4 de una
red Pv4 proporciona una conexin para vincular ubicaciones 6to4.

6

Figura 3. 9: Esquema del tnel entre dos 6to4.

La direccin configurada en %fe) es nica globalmente, donde el
enrutador de lmite de sistema Router A conecta la ubicacin del Sitio A
con la red Pv4. La interfaz %fe) configurada previamente con una
direccin Pv4 antes de que sea posible configurar como una
pseudointerfaz 6to4.

3.&.&.%. +Dne (o$er4
Este mecanismo 6over4 que tambin se denomina tnel
demultidifusin de Pv4, donde 6over4 permite comunicarse entre nodos
Pv6 e Pv4a travs de unainfraestructura Pv4. El tnel 6over4 como se
mencion utiliza la infraestructura Pv4 con capacidad de multidifusin.
Para el correcto funcionamiento de 6over4, la infraestructura Pv4 debe
estarhabilitada para multidifusin Pv4 ilustrada en la Figura 3.10.

Para este mecanismo se debe crear un enlace virtual a travs de un
grupo Pv4 multicast con mbito local organizacional, sin olvidarse que
el mecanismo multicast en Pv4 es opcional. Mientras que las direcciones
Pv6 multicast mapean direcciones Pv4 multicast para ejecutar. Para el
encaminamiento entre Pv6 y el dominio 6over4 es suficiente configurar un
router al menos en una de sus interfaces.

64

Figura 3. 10: Esquema del tnel 6over4.

El mecanismo 6over4 se clasifica en:
a. mbito de aplicacin: dominio.
b. Requisitos de Pv4: conectividad Pv4 multicast entre hosts.
c. Requisitos de las direcciones Pv4: 1 por host.
e. Requisitos de las direcciones Pv6: doble pila.
f. Requisitos de router: configurar mecanismo 6over4 para
encaminamiento entre enlaces virtuales e Pv6.
g. mpacto del NAT: mayor esfuerzo para su funcionamiento debido a
que primero tendr que habilitar el multicast Pv4 a traves de las
NATs.
h. Otros requisitos: para conectar mquinas Pv6 cuyos enlaces
fsicos son diferentes.

3.&.&.(. +Dne +eredo
El tnel Teredo fue diseado para garantizar las conectividades Pv6
de los nodos dual stack, localizados detrs de los dispositivos NAT sobre
dominios Pv4, es decir, que define el encapsulamiento de paquetes Pv6
en datagramas UDP
7
-Pv4 para ser dirigidas a travs de dispositivos NAT
y en internet Pv4. El esquema que se muestra en la figura 3.11indica que

7
UDP,(Protocolo de Datagramas de Usuario)es un protocolo que permite el envo de
datagramas a travs de la red sin que se haya establecido previamente una conexin, ya
que el propio datagrama incorpora suficiente informacin de direccionamiento en su
cabecera. Tampoco tiene confirmacin, ni control de flujo, por lo que
los paquetes pueden adelantarse unos a otros; y tampoco sabemos si ha llegado
correctamente, ya que no hay confirmacin de entrega o de recepcin.

65

un cliente se comunica a travs de un tnel Teredo con hosts
Pv6nativos.(Olvera, Palet, & Vives, 2008)

Figura 3. 11: Esquema del tnel Teredo.
Fuente: http://ipv6.br/entenda/transicao/#tecnicas-teredo

El mecanismo Teredo requieren de servidores y relays Teredo,
donde los servidores por lo general no redireccionan paquetes de datos,
si no que su funcin principal es facilitar el direccionamiento entre clientes
y relays Teredo. De acuerdo al esquema de la figura 3.11, el tnel teredo
consta de los siguientes elementos:
a. Cliente Teredo: se trata de un ordenador ubicado detrs de la
NAT, adquiriendo la direccin Pv6 mediante el servidor Teredo,
encapsulando los paquetes Pv6 en paquetes UDP para ser
enviados hasta el servidor Teredo ms cercano.
b. Relay Teredo: es en realidad un router, que se encarga de
anunciar el prefijo Pv6 de servicio Teredo hacia la red Pv6,
siendo capaz de enviar paquetes UDP sobre el protocolo Pv4
empleando como fuente la direccin Pv4 Anycast reservada para
el servicio Teredo.
c. Servidor Teredo: asigna un prefijo del protocolo Pv6 para el
servicio Teredo, mediante el envo de bajo demanda. Localizan
direcciones del protocolo Pv4 Anycast reservada para el servicio
Teredo, sin guardar estado. El servidor Teredo puede convertirse
en un Relay Teredo, siendo capaz de advertir el prefijo del
protocolo Pv6 de servicio Teredo en la zona del protocolo Pv6.

El mecanismo Teredo se clasifica en:
a. mbito de aplicacin: global o de dominio.

66

b. Requisitos de Pv4: direcciones Pv4 Anycast deben ser
topologicamente correctas, para mantener la compatibilidad con el
filtro de entrada.
c. Requisitos de las direcciones Pv4: 1 direccin Pv4 Anycast para
los servidores incluido el relay.
e. Requisitos de las direcciones Pv6: 1 prefijo para el servidor
Teredo.
f. Requisitos de mquina: ninguno.
h. mpacto del NAT: correcta funcionalidad a travs de las NATs.
i. Otros requisitos: ser compatible con el filtrado de entrada de los
routers.

3.&.&.B. I,A+A'
El tnel SATAP
8
permite crear tneles Pv6-in-Pv4 automticamente
dentro de un sitio Pv4. Cada host solicita a un enrutador dentro del sitio
Pv4 una direccin Pv6 para obtener informacin de enrutamiento, de tal
manera, los paquetes enviados por el protocolo Pv6 son enrutados a
travs del enrutador SATAP y los paquetes destinados hacia otros hosts
dentro del mismo sitio son entregados directamente mediante tneles
SATAP. (Olvera, Palet, & Vives, 2008)

Las direcciones Pv6 se configuran automticamente mediante el
protocolo "descubrimiento de enrutador SATAP, aunque tambin pueden
ser configuradas de manera manual. En la figura3.12 se muestra el
esquema de funcionamiento de los tneles SATAP.

8
+&,-,). por #u# #igla# en ingl/# +ntra&ite,uto0atic-unnel,ddre#ing)rotocol

67

Figura 3. 12: Esquema del tnel SATAP.
Fuente: http://www.1ask2.com/Windows7/Pv6Trans.htm

Para el mecanismo SATAP, la comunicacin se ejecuta
encapsulando automticamente los paquetes Pv6 en Pv4, es decir, que
las cabeceras Pv4 son extradas por las propias direcciones SATAP. Los
ordenadores cuyo soporte es SATAP utilizan la estructura de datos
<<lista de ro-ters potenciales??. Dicha lista aporta el descubrimiento de
vecinos y valida routers existentes en los enlaces SATAP.

En general si est habilitado un enlace SATAP, este debe mostrar
una lista de routers potenciales que se describen a continuacin:
a. El administrador de dominios mantiene registros DNS para
diferentes interfaces SATAP de los routers, para lo cual se
recomienda usar el dominio >>isatap.domainGname??.

b. Los nodos buscan una o ms direcciones de la lista, preguntando
a los DNS por registros anteriores.

c. Posterior a la inicializacin de la lista de routers potenciales, los
nodos revisan peridicamente los registros anteriores, para poder
actualizar la lista de routers.

El mecanismo SATAP se clasifica en:

68

c. Requisitos de las direcciones Pv4: 1 por mquina.
f. Requisitos de mquinas: doble pila.
g. Requisitos de routers: ninguno.
h. mpacto del NAT: no hay operatividad directa de las NATs, aunque
puede operar de manera privada dentro de la red gestionada por el
posible NAT, es decir, que SATAP se emplea como un mecanismo
complementario.
i. Otros requisitos: el descubrimiento de vecinos implica que los
nodos confan en los >>ro-ters advertisements?? recibidos por los
routers del mismo enlace. En otras palabras, solo son confiables
los >>ro-ters advertisements?? pertenecientes a la lista de routers
potenciales.

3.3. +ipos de mecanismos de comunicaci"n entre I'$4 a I'$(
Para la interconexin de islas Pv6 se pueden emplear cualquiera de
los mecanismos presentados en el inciso anterior, habilitando la
comunicacin entre nodos Pv6, pero es necesario establecer una mejor
comunicacin tanto para nodos Pv6 como Pv4. Estos mecanismos se
pueden realizar de algunas maneras, empleando la traduccin a nivel de
red e incluso mediante asignacin temporal de direcciones Pv4 en una
mquina u ordenador Pv6.

Los traductores de protocolos o traduccin, mapean los protocolos a
nivel de campos semejantes de otro protocolo. Recordemos que Pv4
tiene aplicaciones que requieren de informacin de la capa de red,
conocida como >>ftp??, es decir, que la traduccin no solamente a nivel
de red sino tambin a nivel de aplicacin. La mayora de mecanismos de
comunicacin entre nodos Pv4 a Pv6 que se proponen, requieren
implementaciones de ambas pilas de los protocolos de red, denominadas
tambin como >>d-al stac9??cuyas caractersticas son:

69

a. Evaden tneles, ya que los routers no necesitan direcciones Pv4
sino >>d-al stac9??.
b. Evaden traducciones, siempre que se tenga una aplicacin con
soporte Pv4 e Pv6.

3.3.1. *ecanismo D,+*.
DSTM por sus siglas en ingls >>D-al
5tac9%ransitionec@anism??, es un mecanismo que permite a nodos
>>d-al stac9?? comunicarse con otras aplicaciones solamente Pv4,
aunque la pila Pv4 est habilitada pero debe configurarse para lograr
dicha comunicacin. En consecuencia, un nodo Pv4 e Pv6 requieren
direcciones Pv4, la cual es solicitada al servidor DSTM, mientras que la
comunicacin entre el nodo y servidor DSTM es a travs de Pv6.

En ausencia de encapsulamiento Pv4 en redes Pv6, la mquina
>>d-al stac9?? encapsula paquetes Pv4 dentro de paquetes Pv6 hasta
el extremo del tnel, el mismo que lo desencapsula y enviado a
infraestructura Pv4. El encapsulamiento se lo realiza virtualmente, para lo
cual DSTM describe la arquitectura (ver figura 3.13) siguiente:
a. Servidor DSTM, encargada de asignar direcciones Pv4 a clientes
que lo soliciten.

b. Router DSTM, se encarga de realizar la encapsulacin y
desencapsulacin de paquetes asegurando el envo de paquetes.

c. Cliente DSTM, son capaces de configurar dinmicamente su pila
Pv4 y son capaces de establecer tneles Pv4 sobre Pv6.

70

Figura 3. 13: Arquitectura DSTM.
Fuente: http://www.ietf.org/proceedings/54/slides/ngtrans-7.pdf

En la figura 3.14 se muestra el esquema del funcionamiento del
mecanismo DSTM, para el cual una mquina enva paquetes Pv4 previo
contacto con un servidor DSTM. Dicho servidor emplea una direccin Pv4
temporal en forma conjunta con la direccin Pv6 del TEP (Tunnel end
Point), el mismo que acta como extremo remoto del tnel. Con esto se
configura la interfaz tnel del cliente origen y el encapsulamiento se
produce cuando el paquete Pv4 se introduce dentro de un paquete Pv6,
que ya se trata bsicamente del tnel 4over6, al contrario del
funcionamiento del tnel 6over4.

Figura 3. 14: mplementacin esquemtica DSTM.
Fuente: http://www.ietf.org/proceedings/54/slides/ngtrans-7.pdf

71

El mecanismo DSTM se clasifica en:
d. Requisitos de Pv6: extensiones para DHCPv6.
f. Requisitos de mquinas: pila Pv4 e Pv6 con extensiones.
h. mpacto del NAT: se comunican utilizando Pv4 aunque pueden ser
penalizadas por NATs que encuentren en el camino.
i. Otros requisitos: infraestructura de encaminamiento de Pv4.

3.3.&. *ecanismo ,II+.
El mecanismo ST (Stateless P/CMP Translation Algorithm) se
encarga bsicamente de traducir los paquetes a nivel de red entre los
nodos Pv4 e Pv6, dicha traduccin se limita a la cabecera P, es decir,
que la traduccin debe realizarse para cada paquete. Adicional a las
direcciones Pv6 el mecanismo ST emplean direcciones Pv4 traducidas,
haciendo uso de dos tipos de direcciones que se describen a
continuacin:(Nordmark, 2000)
a. Direcciones Pv4 mapeadas, del tipo KK!!0000!a.b.c.dLL que
permiten identificar una mquina Pv4.
b. Direcciones Pv4 traducidas, del tipo <<::ffff:0:a.b.c.d>> que
permiten identificar una mquina Pv6.

En el mtodo ST, el nodo Pv6 obtiene direcciones temporales Pv4
y sirve como medio de enrutamiento para los paquetes. En consecuencia,
las direcciones para ST suelen ser de tres tipos: Pv4, Pv4-traducidas o
Pv4-mapeadas.El mtodo ST no especfica como obtiene direcciones
temporales Pv4, y mucho menos como se registre su DNS. La figura 3.15
se ilustra el mtodo ST empleado para la comunicacin entre redes Pv6
(pequeas) o hosts Pv6 y hosts Pv4.

72

Figura 3. 15: Esquema ST para redes Pv6.
Fuente: http://www.faqs.org/rfcs/rfc2765.html

La figura 3.16 se ilustra el mtodo ST empleado para sitios que
tiene nicamente Pv6 en una red >>d-al stac9??.

Figura 3. 16: Esquema ST para redes >>d-al stac9??.

Los ordenadores que no hagan uso de los traductores ST, deben
de modificar ciertos aspectos para implementar el protocolo Pv6, que son
capaces de:
a. Permitir la transmisin y recepcin de paquetes Pv6 con
direcciones mapeadas Pv4.
b. Determinar si las direcciones Pv4 traducidas, deben ser
asignadas o refrescadas.
c. Asegurar que el mecanismo de seleccin de la direccin Pv4
traducidas slo se utilizan conjuntamente con direcciones Pv4
mapeadas.

7

El mecanismo ST se clasifica en:
c. Requisitos de las direcciones Pv4: 1 direccin temporal por cada
mquina Pv6.
e. Requisitos de las direcciones Pv6: direcciones Pv4 mapeadas y
traducidas que permitan identificar nodos Pv4 e Pv6.
f. Requisitos de mquinas: pila Pv6.
h. mpacto del NAT: son traducidos los paquetes ms de una vez.
i. Otros requisitos: algn mecanismo de asignacin de direcciones
como por ejemplo >>d-al stac9??.

3.3.3. *ecanismo NA+C'+.
El mecanismo NAP-PT *.etBor9 Address %ranslator = 'rotocol
%ranslator+ es aquel que permite la comunicacin entre nodos Pv6 e Pv4
(ambas son nicas y no privadas). NAP-PT es similar al mtodo NAT que
se utiliza en Pv4 pero no es idntico, el mismo consiste en traducir una
direccin Pv4 a otra direccin Pv4. Mientras que los enrutadores NAT-PT
pasan todos los paquetes de una misma sesin.

Figura 3. 17: Esquema NAT-PT.

74

En la figura 3.17 se ilustra el esquema bsico NAT-PT, donde los
Nodos A y B tienen direcciones Pv6 <1ADC!AC&3!!&34%!113. #
1ADC!AC&3!!&34%!1131 respecti$amente=, el Nodo C tiene una
direccin Pv4 (192.68.40.10) y el router NAT-PT tiene asignado un grupo
de direcciones de la subred 168.130.36/34.(Tsirtsis & Srisuresh, 2000)

El funcionamiento del mecanismo NAT-PT consiste en:
a. Las direcciones Pv6 a Pv4definen direcciones falsas Pv6
empleando una direccin Pv4 de destino y anteponiendo el
prefijo NAT, para poder establecer comunicaciones de datos se
debe configurar en el NAT-PT con un prefijo de 96 bits. En
consecuencia, el NAT-PT examina los paquetes para identificar
direcciones falsas, y finalmente traduciendo el paquete a Pv4.

b. Las direcciones Pv4 a Pv6 funcionan como un NAT
bidireccional, donde la traduccin es semejante al inciso a),
generando un paquete Pv6 con direccin origen, mientras que la
direccin falsa Pv6 contiene internamente una direccin Pv4 de
tal manera se inicia la comunicacin.

El mecanismo NAT-PT se clasifica en:
f. Requisitos de mquinas: pila Pv6.
g. Requisitos de routers: ninguno, aunque el router puede ser NAT-
PT.
h. mpacto del NAT: requieren dos o ms niveles de traduccin.
i. Otros requisitos: DNS dentro de una red Pv6.

75

3.3.4. *ecanismo /I,.
El mecanismo BS (Bump in theStack) permite a hosts <<D-al
5tac9??comunicarse con hosts Pv6 utilizando aplicaciones Pv4. Puede
resultar muy til para aquellas aplicaciones que no han migrado (por no
tener el cdigo fuente) a Pv6 para as establecer comunicacin entre
hosts Pv6. En consecuencia, cuando las aplicaciones Pv4 buscan
comunicarse con aplicaciones Pv6, ste realiza el mapeo entre una
direccin Pv6 y una direccin Pv4.(Tsuchiya, Higuchi, & Atarashi, 2000)

El mecanismo BS se encarga de traducir aplicaciones PV4 y redes
situadas por debajo de PV6, en otras palabras, nos referimos al
controlador de interfaz de red. Bsicamente el diseo del stack consta de
una pila >>d-al stac9??, en el cual aade tres mdulos, un traductor, un
nombre de laextensin de la resolucin y la direccin de un mapeado, tal
y como se muestra en la figura 3.18.

Figura 3. 18: Esquema del mecanismo BS.(Dunmore, 2005)

El mecanismo BS admite que hosts se conviertan en traductores
autnomos, para lo cual ya no es necesario un traductor externo. El
mecanismo BS est ubicado en el rea de seguridad del protocolo de

76

internet (P), y posteriormente encargado de verificar datos que pasan
entre TCP/Pv4 y una interface de red, adems de traducirlos a Pv6 y
viceversa.

El mecanismo BS permite la comunicacin de hosts Pv4 al Pv6
pero no existe comunicacin Pv6 al Pv4. mposible de enviar o recibir
algn paquete Pv4 para la red, por lo que una aplicacin Pv4 pretende
comunicar con otra aplicacin Pv4 a travs del BS, el cual produce un
error si no hay mecanismos de traduccin adicionales en algn lugar de la
ruta de comunicacin.

Al igual como ocurre con los mecanismos NAT-PT, ST y BP no
pueden funcionar comunicaciones multicast, ni para aplicaciones que
incorporen direcciones P en sus cargas. Una ALG (Application
LayerGateway) es necesaria para cualquier aplicacin que tiene este
comportamiento.

Por ejemplo, una mquina implementa el mecanismo BS actuando
como originadora de la comunicacin y a la vez como receptora. Se va a
comentar paso a paso cuando la aplicacin Pv4 intenta enviar paquetes a
una aplicacin en una mquina Pv6:
1. La aplicacin Pv4 consulta al DNS si inicia o no la comunicacin
con el extremos remoto.
2. Resuelve la consulta de tipo >>AAAA?? procesada por el mdulo
>>resolver??, el cual solicita al mdulo de mapeo establecer la
correspondencia entre direcciones Pv6 (destino) e Pv4
disponibles.
3. El nombre de extensin resolver, crea un paquete de respuesta
para la aplicacin de tipo A con la direccin Pv4 recin creada.
4. La aplicacin detecta el destino como una direccin Pv4 y
empieza el envo de paquetes.
5. El traductor captura los paquetes Pv4 a travs del mapeador
logrando convertir al Pv4 destino en Pv4 fuente.

77

6. El traductor enva el paquete Pv6 creado por el controlador de
interfaz de red.
7. El paquete llega hasta la direccin Pv6 destino, el mismo que se
encarga de enviar un paquete Pv6 hacia el nodo origen de la
comunicacin.
8. El paquete Pv6 llega hasta el nodo origen.
9. Finalmente se traduce el paquete Pv6 a travs de la tabla de
asignaciones del mapeador, entregando el paquete Pv4 as
construido a la aplicacin final.

Cuando entra en funcionamiento el mecanismo BS se comporta
como un receptor, dicha comunicacin se explica paso a paso:
1. Un paquete Pv6 adquiere al nodo implementado por el
mecanismo BS.
2. La traduccin obtiene el paquete y lo traduce, a travs del
mdulo de mapeo para conseguir la correspondencia entre las
direcciones Pv6 (destino) e Pv4.
3. La traduccin entrega un paquete Pv4 creado en las
aplicaciones Pv4.
4. Las aplicaciones Pv4 como respuesta enva un paquete Pv4 al
nodo inicial de la comunicacin.
5. Para el presente paso hay que seguir los pasos del ejemplo
anterior.

El mecanismo BS se clasifica en:
a. mbito de aplicacin: host.
c. Requisitos de las direcciones Pv4: espacio privado de direcciones
por mquina.
f. Requisitos de hosts: doble pila ms extensiones.

78

h. mpacto del NAT: hay presencia de una NAT aunque no hay efecto
en el trfico Pv6 debido a que las direcciones Pv4 son usadas
internamente.
i. Otros requisitos: direcciones de una forma literal.

3.3.%. *ecanismo +R+.
El mecanismo TRT *%ransport 7ela$ %ranslator+ especificado por el
requisito RFC3142, establece que los hosts Pv6 intercambien el trfico
TCP o UDP con hosts Pv4. Es decir, que permite comunicarse
directamente entre aplicaciones Pv6 e Pv4. A diferencia del mecanismo
NAT-PT, el TRT acta a nivel de la capa de transporte, y a diferencia del
BS, acta como una pasarela entre ambos protocolos, estableciendo una
conexin para Pv6 y otra para Pv4 permitiendo el reenvo de paquetes
entre ambas direcciones.(Hagino & Yamamoto, 2001)

Ninguna modificacin de los host es necesaria, el sistema TRT
puede ser muy fcil de instalar en las redes con capacidades de Pv6.El
mecanismo TRT es traducido y ejecutado en un nodo >>d-al stac9??
para as establecer la comunicacin con un host (cliente) o con el
servidor. Al implementar una red Pv6 es necesario mantener el acceso a
todos los recursos Pv4 de redes externas, tales como servidores web
Pv4 y es por este motivo que emplearemos el mecanismo de pasarela de
traduccin a nivel de transporte (TRT).

El mecanismo TRT posee ciertas ventajas con respecto a los dems
mecanismos, como por ejemplo, no tienen problemas en traduccin de
cabeceras Pv4/Pv6 y de fragmentacin. Las desventajas del TRT son:
1. TRT soporta nicamente trfico bidireccional.
2. TRT requiere de un sistema de almacenamiento de estado entre
los nodos Pv4 e Pv6 para poder comunicarse, similar a los
sistemas NAT.
3. TRT requiere de un cdigo especial para reenviar protocolos
incompatibles con NAT (NAT--nfriendl$+.

79

Las redes Pv6 e Pv4 son configuradas de tal manera que tanto los
paquetes Pv6 como Pv4 son enviados a direcciones cuyos prefijos de
red especiales son enrutados por un nodo remoto TRT. En la figura 3.19
TRT Pv6/Pv4permite interceptar las sesiones de transporte mediante los
nodos como punto final de destino de una sesin Pv6 y enva hacia el
nodo del servidor como una sesin Pv4, copiando as todos los datos
recibidos en cada sesin.(Dunmore, 2005)

Figura 3. 19: Esquema del mecanismo TRT. (Dunmore, 2005)

El mecanismo TRT se clasifica en:
c. Requisitos de las direcciones Pv4: 1 por sitio.
e. Requisitos de las direcciones Pv6: un prefijo para encaminar los
paquetes hacia el traductor.
f. Requisitos de mquinas: ninguno.
g. Requisitos de routers: ninguno, pero requiere de una mquina TRT.
h. mpacto del NAT: depende de la aplicacin.
i. Otros requisitos: servidor DNS para mapeo de direcciones Pv4 a
direcciones Pv6.

80

3.3.(. *ecanismo ,oc@s(4.
El mecanismo Socks64 se basa en el proxy SOCKS convencional,
dicho mecanismo est compuesto por una puerta de enlace SOCKS
implementado como un host de pila dual Pv4/Pv6 y un cliente de acogida
implementado con un software llamado SOCKS LB entre las capas de
aplicacin y transporte (ver figura 3.20). Esto intercepta las consultas DNS
y responde con falsas direcciones Pv4, de modo que cuando el cliente
hace una llamada a la conexin AP, donde LB SOCKS sustituye la
direccin falsa original y enva el paquete, llamado SOCKS al proxy que
realiza la actual bsqueda de DNS. (Kitamura, 2011)

Figura 3. 20: Diagrama del mecanismo Socks. (Dunmore, 2005)

Si el servidor DNS responde con un registro AAAA, el proxy abre un
socket Pv6, de lo contrario, se abre un socket Pv4. Definido en el RFC
3089, la solucin SOCKS64 es bidireccional, lo que permite anfitriones
hosts Pv4 e Pv6 para iniciar sesiones. Sin embargo, es necesario el uso
de direcciones Pv4 pblicas.

En la figura 3.21 se muestra la configuracin del proxy SOCKS, el
mismo que se define como un mecanismo de reenvo de la capa de
transporte, permitiendo hosts con direcciones privadas o con acceso
limitado a travs de firewalls que puedan tener libre acceso a los recursos
de nternet. Un proxy SOCKS para Pv4 se aloja por lo general en una

81

gran base dual con una direccin privada y otros pblicos. l recibe
conexiones desde hosts internos por su interfaz P privada y crea
conexiones con servidores en nternet a travs de su interfaz pblica. Del
mismo modo, un SOCKS64 proxy est alojado en un servidor de base
dual con una direccin Pv6 y otra direccin Pv4 pblica. Se puede recibir
por sus conexiones de interfaz de Pv6 y redirigirlos por su interfaz Pv4 y
viceversa.

Figura 3. 21: Esquema del proxy Socks64. (Dunmore, 2005)

Esta solucin puede llegar a ser la ideal en caso de que el 'sitio' est
utilizando ya SOCKS. Con un gateway de tipo SOCKS64 se puede
permitir conectar a los clientes tanto a nodos Pv4 como Pv6, sin los
tpicos problemas asociados a los tneles (fragmentacin y lmite de
saltos).(Kitamura, 2011)

El mecanismo Socks64 se clasifica en:
c. Requisitos de las direcciones Pv4: 1 por pasarela o servidor
Socks.
d. Requisitos de Pv6: >=1 por sitio.

82

f. Requisitos de mquinas: los clientes deben ser socksificados.
h. mpacto del NAT: operacin conjunta entre servidores NAT y
Socks.
i. Otros requisitos: servidor Socks emplea el >>d-al stac9??.

3.3.B. *ecanismo /IA.
El mecanismo BA *8-mp in t@e A'#+ es muy similar al mecanismo
BS, dicho mecanismo agrega una AP de traduccin entre el AP de
socket y mdulos TPC/hosts P pila dual, permitiendo aplicaciones de
comunicacin con anfitriones Pv4 e Pv6, lo que refleja las funciones de
la toma en socket Pv4 a Pv6 y viceversa.

El mecanismo BA est descrito por el RFC 3338, en la cual tres
mdulos son aadidos (ver figura 3.21):

Figura 3. 22: Esquema del mecanismo BA. (Dunmore, 2005)

8

a. El nombre de extensin de resolucin (extensi*n name
resolver), y las direcciones de mapeo (address mapper)
funcionan de la misma manera que el BS.
b. La funcin de mapeo (f&nction mapper), detecta las llamadas de
las funciones del socket Pv4 e invoca las funciones
correspondientes del socket Pv6 y viceversa.

El BA tiene dos ventajas sobre BS: no dependen del controlador de
interfaz de red y no introducir una sobrecarga en la traduccin de los
encabezados del paquete. Sin embargo, tampoco es compatible con la
comunicacin multicast.

El mecanismo Socks64 se clasifica en:
a. mbito de aplicacin: mquina.
c. Requisitos de las direcciones Pv4: espacio privado de direcciones
por mquina.
f. Requisitos de mquinas: doble pila ms extensiones.
h. mpacto del NAT: no resulta afectado por la presencia de NATs.
i. Otros requisitos: aplicaciones que utilizan direcciones de una forma
literal.

3.4. AnIisis comparati$o de os mecanismos de transici"n I'$4 a
I'$(.
Una vez detallado cada uno de los mecanismos propuestos para la
transicin de Pv4 a Pv6 y que de una u otra manera conllevarn a la
migracin total de direcciones Pv6. A continuacin se presenta el anlisis
comparativo de los diferentes mecanismos de transicin:

84

3.4.1. AnIisis comparati$o de os mecanismos de
intercone8i"n.
1. Para el caso de los t+neles config&rados cuyo mecanismo es el
ms empleado para obtener conectividad Pv6 de manera estable y
sin complicaciones. Sin embargo, dicho tnel requiere de
configuracin manual en ambos extremos, mediante el subrango
de direcciones Pv6 sin afectar la configuracin del tnel. Es decir,
que para el tnel >>t-nnelbro9er??solo permite resolver la
configuracin de un extremo, aunque presenta inconvenientes de
escalabilidad.

2. Debido a su simplicidad de configuracin el tnel 6to4, permite
obtener no slo una direccin Pv6 sino tambin la direccin Pv4.
Muy til al momento de conectividad Pv6 mediante los
proveedores de servicio que hasta ahora permiten conectividad
Pv4.

3. El mecanismo 6over4 es poco empleado, por ser decadente, es
decir, obsoleto debido a que requieren del servicio multicast en
direcciones Pv4 para que exista interconexin.

4. Por problemas de seguridad los tneles automticos no son
recomendables implementarlos, debido a que los paquetes son
transmitidos mediante encapsulacin automtica sobre Pv4, lo que
provocara un sinnmero de ataques. Aunque cualquier mecanismo
que encapsule de forma automtica direcciones Pv4 embebidas
dentro de la misma direccin Pv6, tendran inconvenientes de
seguridad (ataques), pero ya existen actualmente distintas
soluciones que se relacionan con el uso de direcciones mapeadas.

5. Mientras el mecanismo SATAP despliega un mbito de
aplicabilidad de dominio, lo que significa que requiere siempre de
una direccin Pv4 por cada mquina.

85

6. En tanto el mecanismo TEREDO es mucho ms flexible que los
dems mecanismos analizados, es decir, que permite ejecutar la
transicin a travs de las NAT's.

3.4.&. AnIisis comparati$o de os mecanismosde
comunicaci"n.
1. Para el mecanismo TRT que se presenta como muy til en la
transicin, aunque el nico inconveniente es en aplicaciones no
compatibles con las NAT's. Actualmente se conocen
implementaciones de TRT bajo TCP, mientras que para UDP son
complicadas

2. El mecanismo DSTM requiere tanto del protocolo DHCPv6 y los
tneles Pv4/Pv6, permitiendo la comunicacin entre un dominio
Pv6 y mquinas con direccin Pv4, sin necesidad de emplear el
encaminamiento Pv4, es decir, que las mquinas Pv6 no
requieren de direcciones Pv4, aunque si deben ser >>d-al
stac9??. Por ltimo DSTM evita utilizar NAT's para comunicaciones
solamente entre Pv4 e Pv6.

3. En tanto que los mecanismos Socks64 y BA manejan un mbito de
aplicabilidad muy reducido debido a las aplicaciones de
interoperabilidad evitando una migracin a corto plazo. Es decir,
que ambos mecanismos permiten la interoperabilidad solo a nivel
P.

4. Mientras el mecanismo BS casi similar al mecanismo BA, la
diferencia es que deben modificar la pila P permitiendo as la
interoperabilidad de aplicaciones en mquinas Pv4 sobre Pv6.
Aunque no es recomendable implantar BS, por lo expuesto ya que
resulta ms fcil hacer que una mquina se transforme en un host
del tipo >>d-al stac9?? y agregar el mecanismo BA.

86

5. El mecanismo ST resulta ser ms robusto, que al no tener estado,
no presenta problemas de escalado en las conexiones. Durante el
desarrollo del presente trabajo investigativo se pudo conocer que
mediante la implementacin del ST se han obtenido mejores
resultados de interoperabilidad debido a su robustez.

6. Finalmente el mecanismo NAT-PT es muy utilizado en negocios
corporativos de mbito privado y las aplicaciones no requieren de
NAT's. Aunque tendra un pequeo inconvenientes si trabaja el
mecanismo NAT-PT conjuntamente con el nivel de aplicacin DNS-
ALG.

3.%. I'$( en e Ecuador.
Las especificaciones bsicas de los protocolos de internet Pv6
fueron establecidas hace aproximadamente 15 aos; sin embargo, su
utilizacin estuvo por mucho tiempo circunscrita a unas pocas redes, en
su mayora de carcter universitario o de investigacin, pero esto ha
comenzado a cambiar con el advenimiento de sistemas operativos que
traen Pv6 habilitado por defecto (Windows Vista, 7) y especialmente con
la realizacin del "Pv6 Day, que se desarroll el 6 de junio de 2011, un
evento organizado y coordinado por la nternet Society (SOC) a travs del
cual - durante 24 horas - grandes redes y proveedores de contenido
(Facebook, Yahoo, Google entre otras) habilitaron acceso por Pv6 a sus
pginas principales.

El 6 de junio de 2012, SOC organiz el "Pv6 Launch, los
participantes de este evento dejaron habilitado Pv6 en sus redes ese da
y de forma indefinida. A continuacin se da un vistazo al estado de la
implementacin de Pv6 en Ecuador:

Bloques Pv6 asignados y utilizados (al 8 de abril de 2012):
23 bloques Pv6 asignados/distribuidos por LACNC a
organizaciones ecuatorianas.

87

12 bloques utilizados (vistos en el nternet Global)
11 organizaciones diferentes utilizan prefijos Pv6

Oferta de servicios consoporte de Pv6:
SPs que pueden proveer trnsito Pv6 nativo: 3
SPs que proveen servicio HOME con soporte Pv6 nativo:0
El punto de intercambio de trfico local de nternet (NAP.EC)
tienePv6 nativo habilitado
El dominio .EC tiene un servidor con Pv6 fuera del Ecuador y otro
en NAP.EC. NC.EC acepta registros AAAA para dominios .EC

Pginas locales con soporte Pv6:
www.aeprovi.org.ec
www.ipv6tf.ec
www.cedia.org.ec
Pginas de algunas universidades ecuatorianas (listado en
www.ipv6tf.ec)

3.(. 'an Naciona de Contro +9cnico a tra$9s de ,2'ER+EL
-
#
*IN+EL
1.
.
Como se describi, la transicin a Pv6 dentro del territorio
ecuatoriano se est iniciando, por lo cual y por iniciativa de AEPROV
11
se
cre la Fuerza de Trabajo de Pv6 de Ecuador (Pv6TF-EC) con los
siguientes objetivos:
Ser fuente de informacin relacionada con el Protocolo de nternet
versin 6 (Pv6).
Coordinar labores de capacitacin y difusin sobre Pv6.

9
SUPERTEL: Superintendencia de Telecomunicaciones del Ecuador.
10
MNTEL: Ministerio de Telecomunicaciones y de la Sociedad de la nformacin del
Ecuador.
11
AEPROV: la Asociacin de Empresas Proveedoras de nternet, Valor Agregado,
Portadores y Tecnologas de la nformacin. Aqu podr encontrar informacin
actualizada acerca de las actividades que realiza la asociacin y sobre el sector de las
telecomunicaciones y tecnologas de la informacin en general con mbito en el
Ecuador. http://www.aeprovi.org.ec/

88

Coordinar los esfuerzos de los diferentes actores del nternet
ecuatoriano para una eficaz y pronta adopcin del Pv6.
Fomentar el uso de Pv6.
Establecer permanente comunicacin e identificar oportunidades
de colaboracin con los Grupos de Trabajo de otros pases y
regiones.
Elaborar un plan de accin para la implementacin de Pv6 en el
pas y propiciar su uso.

El Pv6TF-EC no es una persona jurdica, es simplemente un grupo
de trabajo con participacin abierta; se busca incentivar la participacin de
ecuatorianas y ecuatorianos de los siguientes sectores: industria,
gobierno, sector educativo, usuarios. El Grupo de Trabajo cuenta con un
portal de nternet (www.ipv6tf.ec) con soporte de Pv6 nativo y alojado en
Ecuador. La participacin se realiza mediante la suscripcin a la lista de
correo electrnico foro@ipv6tf.ec(la suscripcin se realiza a travs del
portal).

El Art. 313 de la Constitucin de la Repblica dispone que el Estado
se reserva el derecho de administrar, regular, controlar y gestionar los
sectores estratgicos, esto es, aquellos que por su trascendencia y
magnitud tienen influencia econmica, social, poltica o ambiental;
sectores estratgicos entre los cuales est el sector de las
telecomunicaciones, y en representacin del estado actuarn la
SUPERTEL y MNTEL.

La ,2'ER+EL se encargar de controlar el proceso de transicin de
Pv4 a Pv6, a travs de parmetros tcnicos, es decir, que tipo de
infraestructura tecnolgica (hardware) van a emplear la SPs para hacer
posible el proceso de transicin y posterior migracin a Pv6. En el Anexo
A se detallan los parmetros de calidad para la provisin de servicios de
valor agregado de nternet.

89

El Ministerio de Telecomunicaciones y de la Sociedad de la
nformacin (MNTEL) mediante el Acuerdo N 039-2012, define lo
siguiente con respecto a Pv6:
a. Que, dentro del Plan de Accin eLAC 2015, la meta 4 insta a los
pases miembros a colaborar y trabajar en forma coordinada con
todos los actores regionales, incluidos los sectores acadmico y
comercial, la comunidad tcnica y las organizaciones que
participan en el tema, para que la regin logre un amplio
despliegue del Protocolo de nternet versin 6 (Pv6), as mismo
hace un llamado a implementar con brevedad planes nacionales
que permitan acceder a los portales de servicios pblicos
gubernamentales de los pases de la regin a travs de Pv6 y
que las redes estatales trabajen de forma nativa con Pv6.
b. Que, en este contexto y mediante Acuerdo N 0133 del 25 de
marzo del 2011 el MNTEL, requiri a las nstituciones y
Organismos sealados en el Art. 225 de la Constitucin de la
Repblica del Ecuador que en los nuevos procedimientos de
contratacin de equipamiento tecnolgico, productos y
aplicaciones que utilicen el Protocolo de nternet y que se
efecten a partir de la fecha de publicacin en el Registro Oficial
del mencionado acuerdo, tengan como exigencia primordial el
soporte y compatibilidad con Pv6.
c. Que, con Acuerdo N 007-2012 del 18 de enero del 2012, el
MNTEL emiti lineamientos de poltica pblica vinculados con la
incorporacin de Pv6 en sitios web y aplicativos del sector
pblico, en el ccTLD.ec y en el curso normal de trfico Pv6 en
las redes de SPs y Portadores.
d. Que, en la reunin N XX, el Comit Consultivo Permanente de
Telecomunicaciones CCPP CTEL-OEA (ver Anexo B) aprob las
medidas regionales de fomento y adopcin de Pv6 en la Regin,
las cuales fueron presentadas por Ecuador en Buenos Aires,
Argentina el 19 de mayo del 2012, mediante documento N 2608.
e. Que, es necesario que el MNTEL como rgano rector del
desarrollo de las Tecnologas de la nformacin y Comunicacin,

90

dentro de sus competencias, coordine con las entidades del
sector pblico la coexistencia de los protocolos Pv4 e Pv6.

Esto conlleva al MNTEL en ejercicio de sus atribuciones, acordar los
siguientes dos artculos.
Artcuo 1.C Aprobar las siguientes estrategias de accin para el
fomento en la adopcin y coexistencia de los protocolos Pv4 e Pv6 en
todo el territorio nacional bajo las siguientes estrategias:
1. El proceso de incorporacin y adopcin del Protocolo de nternet
Pv6 en Ecuador, ser impulsado por el MNTEL, dentro del
programa de Recursos de Banda Ancha, que forma parte del
Plan Nacional de Banda Ancha.
2. Las nstituciones y Organismos del Sector Pblico sealados en
el Art. 225 de la Constitucin de la Repblica del Ecuador,
debern realizar las gestiones necesarias para que implementen
sus sitios web y plataformas de servicios electrnicos, con el
soporte y compatibilidad con el protocolo Pv6 de manera
coexistente con el protocolo Pv4, en el plazo de un ao contado
a partir de la entrada en vigencia del presente acuerdo.
3. Las empresas pblicas de telecomunicaciones, realizarn las
acciones que correspondan, para que en el plazo de 45 das
contados a partir de la publicacin del presente acuerdo, admitan
en sus redes, plataformas y sistemas el curso normal de trfico
de Pv6 nativo en coexistencia con Pv4.
4. ncorporacin del protocolo Pv6 de forma coexistente con Pv4
en los sitios Web www.mintel.gob.ec, www.mintel.gob.ec y
www.conatel.gob.ec as como en las plataformas de servicios
electrnicos asociadas a los portales web tanto del MNTEL,
SUPERTEL y CONATEL.
5. El MNTEL organizar talleres, charlas, foros y jornadas terico-
prcticas sobre aspectos tcnicos Pv6, de carcter gratuito a los
largo del territorio nacional, con participacin de expertos
internacionales con amplia experiencia en el despliegue real de
Pv6.

91

6. El MNTEL en el plazo de 90 das contados a partir de la
publicacin del acuerdo N 039-2012, publicar el "Plan de
recursos y adquisiciones de tecnologa con soporte Pv6, el cual
servir como marco de referencia para inclusin del nuevo
protocolo en los procesos de adquisicin de infraestructura,
servicios, y aplicaciones para garantizar el adecuado soporte de
Pv6 tanto en el sector pblico como privado.

Artcuo &.C El MNTEL se encargar del seguimiento y monitoreo
respecto al cumplimiento del presente acuerdo, en colaboracin con la
SUPERTEL.

De acuerdo con lo descrito en el Plan Nacional de Control Tcnico el
MNTEL, SUPERTEL y CONATEL son los entes pblicos que se
encargarn de verificar la calidad de los servicios de valor agregado
(SVA) de internet.

92

Captuo 4! ,imuaciones de mecanismos de transici"n.

4.1. ,imuaci"n de os mecanismos +unne /ro@er.
Para la simulacin de los mecanismos Broker se emplearn los
simuladores virtuales online de freenet6 y hurricane. Estas simulaciones
se basan de acuerdo a las propuestas de los diferentes mecanismos de
transicin expuestos en el captulo anterior.

4.1.1. ,imuaci"n de un 7ost en MIND5M, B mediante 1reenet(.
Para la presente prueba de simulacin de un tnel Broker,
emplearemos una red LAN con protocolo Pv4 detrs de un ADSL con
direccionamiento P pblico. nicialmente no se considerar ningn
Firewall entre el ADSL y la LAN. Mediante Freenet6 crearemos un tnel
con host (Windows) de una red LAN (por detrs de una NAT), que permita
obtener conectividad Pv6 para un host con Pv4. Previamente a la
simulacin debemos considerar lo siguiente:
a. En primer lugar, configuraremos al host en la parte cliente del tnel
denominado gogoCLENT, en la cual el cliente interactuar con el
servidor denominado gogoSERVER.

b. En segundo lugar, utilizaremos al protocolo TSP, permitiendo que
el tnel de datos se mantenga esttico. Es decir, que gogoCLENT
se conecta a gogoSERVER para obtener informacin relativa al
tnel mediante el protocolo TSP. En caso de que el host crear al
tnel y se encuentre detrs de un FREWALL, abriramos el puerto
3653. 'ara este acIpite no traba6amos detrIs de 1IREMALL en
consecuencia no abriremos ningDn puerto.

c. En tercer lugar, los cdigos fuente deben ser iguales para todas las
plataformas cliente.

d. En cuarto lugar, y de manera opcional si deseamos configurar al
cliente para conexin a un nico gogoSERVER o mltiples
SERVDORES. Esto permite obtener mejor calidad de servicio para

9

los usuarios al momento de conectarse al servidor ms cercano y
manteniendo la redundancia, que ante cualquier suceso en el que
un servidor no est disponible el tnel siga funcionando.

e. Y en quinto lugar, emplearemos una interfaz grfica para Microsoft
Windows, permitiendo una fcil configuracin del tnel y a la vez
ofreciendo un informe del estado de servicio.

Antes de realizar la simulacin debemos dirigirnos a la pgina web:
http://www.gogo6.com/freenet6/tunnelbroker, para proceder a descargar el
programa gogoCLENT Basic Versin. En dicha pgina debern
registrarse previamente para proceder a descargar el programa en
mencin. Una vez descargado se proceder a la instalacin y
configuraciones respectivas del tnel Broker.

El software instalado gogoCLENT se lo puede visualizar en el botn
niciar de Windows 7, tal como se muestra en la figura 4.1.

Figura 4. 1: Software gogoCLENT instalado en Windows 7 de 64 bits.

94

Al abrir la carpeta gogo6 escogemos la opcin gogoCLENT Utility, la
misma debe tener permisos de administrador, permitiendo la conexin
mediante identificacin o de manera annima al servidor freenet6, tal
como se muestra en la figura 4.2.

Figura 4. 2: Ventana de gogoCLENT Utility.

Hay dos maneras de conectarse al servidor de pruebas:
a. Seleccionamos el tipo de conexin annima "Connect
anon#mous#N mientras que en el "Server Address
escribiremos "anon#mous.0reenet(.netN.Al ser una conexin
annima, nos permitir navegar con Pv6 en nternet, aunque
nadie accedera a pginas Web que tengamos en nuestra
mquina. Adems, no dar una direccin pv6 a ningn host de
nuestra LAN.
b. En cambio s escogemosOConnect 2sing t4e 1ooJing
CredentiasN y al Server Address"aut4enticated.0reenet(.net.
Para esta opcin es requisito necesario ser usuario y la

95

contrasea del registro realizado en freenet. En este caso
tendremos todas las opciones comentadas si las tenemos activas
en la configuracin avanzada que se explica ms adelante.

No es conveniente activar Oaunc4 de gogocientser$ices#stem at
startupN pero al ser activada, pondr al tnel en marcha cuando
encendamos o reiniciemos las computadoras, es decir, que
predeterminadamente tenemos una red con Pv6. De la figura 4.2
escogemos la pestaa Status, en la que se puede observar toda la
informacin que freenet6 nos ha asignado.

En la figura 4.3 se muestra el estado status, en la cual nos indica
que tenemos una configuracin pv6-in-UDP-pv4 Tunnel (NAT
Transversal), es decir, que estamos detrs de una NAT.

Figura 4. 3: Status de conexin Broker de gogoCLENT Utility.

96

Como podemos observar de la figura 4.3, la longitud del prefijo
asignado es de 64 bits. Para esta simulacin es importante reconocer
cuando los tneles tienen conexin annima o autenticada, debido a que
el prefijo cambia respecto a la conexin. Es decir, que para la conexin
annima, el prefijo tiene la forma 2001:05c0:1000:a!: /64 (finaliza con a)la
direccin Pv6 viene asociada con cada conexin del tnel mientras que
en la conexin autenticada, en donde el segundo prefijo tiene la forma
2001:05c0:1000!b:: /64 (acaba con b) y la direccin Pv6 es asignada de
forma permanente al usuario sin cambiarse aunque el usuario se desplace
a otra Pv4.

Los tneles creados expirarn pocos minutos despus de que el
cliente se haya desconectado. Mientras tanto, procedemos a comprobar la
conexin Pv6 (ver figura 4.4) a travs del cmd, dndole un ping a la
direccin de google.

Figura 4. 4: Estado de conexin mediante Pv6.

Este tipo de pruebas se realizaron en los laboratorios de la
SUPERTEL para comprobar que la SPs en este caso Claro (Banda
Ancha) trabaje con el mecanismo de transicin Tunnel Broker. Este
software es libre, servir para controlar y supervisar por parte de la
SUPERTEL a todos y cada uno de las SPs.

97

Finalmente cabe recalcar que el programa gogoCLENT no requiere
de programacin de alto nivel, sino ms bien de una correcta
configuracin, tener acceso a la red gogoCLENT. Este software puede
ser utilizado en Universidades para el despliegue de otras
investigaciones.

4.1.&. ,imuaci"n de un tDne de 0ireJa en MIND5M, B mediante
7urricane.
Similarmente a la primera simulacin, la red disponible es una LAN
Pv4 detrs de un Firewall Debian mediante la conexin de un ADSL con
P pblica esttica. El objetivo de la presente simulacin consiste en crear
un tnel Broker desde un firewall dotndole de una direccin Pv6 hacia
internet y que acceda sin problemas a varias pginas web con
direccionamiento Pv6.

Para la simulacin de este acpite, se utilizar la pgina web
http://tunnelbroker.net mostrada por la figura 4.5. En dicha pgina hay que
suscribirme y posteriormente recibirn un email para poder acceder a la
plataforma Hurricane Electric (nternet Services).

Figura 4. 5: Pgina web del Tunnel Broker Pv6.

98

Una vez realizado lo indicado, se proceder a ingresar con el
respectivo usuario, posteriormente elegimos OCreate reguar tunneNla
cual permite visualizar una ventana (ver figura 4.6), la misma que solicita
una direccin P pblica, que por lo general es la misma de nuestro ADSL.

Figura 4. 6: Creacin regular de un tnel Broker.

La figura 4.6 nos muestra toda la informacin, cuyo direccionamiento
Pv4 e Pv6 ocurren en ambos extremos del tnel. Adicional, se observa
un prefijo Pv6 asignado exclusivamente para dar una direccin Pv6 a
cada host de la red LAN localizada por detrs del Firewall.

Posterior a esto procedemos a realizar la instalacin del Debian.
Provisionalmente el pc u ordenador es un host con distribucin Debian, el
mismo maneja dos tarjetas de Red, una tarjeta que opera solo para la red
LAN (eth1) y la otra a la Red del ADSL (eth0). Adicionalmente, el pc o
Host es un Firewall y un servidor Apache.

Para una correcta simulacin, la red Pv4 debe cumplir una serie de
requisitos:

99

a. La Pv4 pblica del ADSL tiene que ser esttica.
b. La direccin Pv4 de cada host de la LAN puede ser esttica o
dinmica.
c. El tnel diseado o creado es autenticado, es decir, que no existe
annimos como en Freenet6.

Una limitante del uso de la plataforma web de Hurricane Electric, es
que cada usuario puede crear hasta 5 tneles. Primeros pasos:
1. Probar que Kernel de Deban admite Pv6. Este debe ser posterior
a la versin 2.6.
#cat ;proc;net;i0Pinet( GGecho 'Pv6 sistema preparado!' QQ echo 'No se
encuentra el soporte Pv6. Compile el Kernel!!'

2. Probar que el mdulo Pv6 est cargado:
modprobe Pv6
o
lsmod | grep ipv6

Resutado! ipv6 41142518

Creamos un archivo que tiene las ordenes iptabes para una
correcta configuracin del Firewall. Al archivo le damos el nombre de
"permitir y lo almacenamos en la ruta /etc/init.d
apac4eaeg!;etc;init.dR cat permitir
RS;bin;bas4
ptT;sbin;iptabes
0or +A/LE in 0iter nat
do
Upt Ct U+A/LE C1
Upt Ct U+A/LE CV
Upt Ct U+A/LE CW
done
ec4o 1 L;proc;s#s;net;ip$4;ipP0orJard
ec4o 1 L;proc;s#s;net;ip$(;con0;a;0orJarding
iptabes Ct nat CA '5,+R52+ING CCprotoco S 41 Co et4. C6 *A,X2ERADE

100

Adems de poner polticas por defecto Aceptar3 se da la orden de
forwardear entre las tarjetas los paquetes Pv4 e Pv6. Tambin, se da la
orden de enmascarar nicamente los paquetes Pv4. Los paquetes Pv6
usan el protocolo 41 y se le est indicando al Firewall que no enmascare
estos paquetes. Este archivo tiene un enlace creado en ;etc;rc&.d para
que se ejecute cada vez que se inicia el Host.

;etc;init.dR c4mod BBB permitir
;etc;init.dR n Ys ;etc;init.d;permitir ;etc;rc&.d;,--Ppermitir
Nrdenes para crear el tOnel;
ip tunne add 4eCip$( mode sit remote &1(.((.)..&( oca 1..1..1..%. tt &%%

5inta0is;
ip tunne ZaddQc4angeQdeete[ nombrePtune mode ZipipQsitQgre[ remote
Zdireci. Ip$4 b bro@er[ oca Za ip de nuestro 4ost[ de$ Zperi0erico[

Los argumentos posibles son:
name NOMBRE -- selecciona el nombre del tnel
mode MODO -- hay 3 modos disponibles: ipip, sit y gre

El modo ipip corresponde a un simple tnel P sobre P. Se
encapsulan los paquetes sin ms. El modo sit se usa para tneles Pv6. El
modo gre corresponde a los tneles GRE especificados por la compaa
Cisco, que son tneles P sobre P cifrados.

remote DRECCON -- direccin de 'salida' del tnel
local DRECCON -- direccin local de 'entrada' del tnel
PERFERCO-- nombre del perifrico a travs del que se envan los
paquetes

ip tun s4oJ Y
Esta orden muestra los tneles
ip in@ set 4eCip$( up
Esta orden sirve para levantar el tnel llamado he-ipv6

101

ipaddr add &..1!4B.!10.)!B44!!&;(4 de$ 4eCip$(
Permite asignar una direccin Pv6 al extremo local del tnel

ip route add !!;. de$ 4eCip$(
Permite poner una ruta esttica. Cualquier paquete que est destinado a
una direccin Pv6 deber salir por el tnel llamado he-ipv6.

ip C0 inet( addr
El -f significa family, y al poner inet6 hace referencia a la familia Pv6. Si
no se pone nada por defecto es Pv4. Esta orden tiene carcter
informativo y muestra las direcciones Pv6. Todas las rdenes juntas
forman el script para crear el tnel. Se puede usar cualquier editor de
texto (nano, vi,..):

apac4eaeg!;etc;init.dR nano tune
ip tunne add 4eCip$( mode sit remote &1(.((.)..&( oca 1..1..1..%. tt &%%
ip in@ set 4eCip$( up
ipaddr add &..1!4B.!10.)!B44!!&;(4 de$ 4eCip$(
ip route add !!;. de$ 4eCip$(
ip C0
inet(addr ;etc;init.dR c4mod BBB tune
;etc;init.dR n Ys ;etc;init.d;tune ;etc;rc&.d;,--Ptune

A este archivo se le ha dado permisos de ejecucin, se ha creado el
enlace a rc2.d para su ejecucin en el arranque. La orden i0con0igme
muestra (ver figura 4.7):
apac4eaeg!;4ome;apac4eJebR i0con0ig

102

Figura 4. 7: Resultados de la redes LAN.

Para poner el demonio radvd en marcha damos la orden:
apac4eaeg!;etc;init.dR ;etc;rad$drestart
Stopping radvd: radvd.
Starting radvd: radvd.

Para que se ejecute de forma automtica el radvd deberemos en el
archivo rc.local que se encuentra en /etc aadir la lnea
;etc;rad$d.con0restart. Este archivo tiene un enlace a rc2.d llamado
S99rc.local. ;etcR nano rc.ocaAadir la lnea: /etc/radvd.confrestart,
como se muestra en la figura 4.8

Figura 4. 8: Ejecucin automtica del tnel Broker.

10

A partir de ah y desde cualquier host o mquina de la red LAN
tenemos posibilidades de consultar Pginas web Pv6 en nternet.
Adems, podemos ver nuestra pgina web en el Firewall desde cualquier
host que tenga una direccin Pv6. Consultando la informacin de la
interface del host que est detrs de la LAN observamos en la figura 4.9:

Figura 4. 9: pconfig del mecanismo tnel Broker.

El paquete de datos sale a nternet desde un host o mquina de una
red LAN, aunque de manera inicial ser enviado a la interface del Firewall
local (fe80), una vez el paquete ha llegado al router este consulta en su
tabla de enrutamiento la direccin pv6 por la que debe salir para llegar a
internet. En la figura 4.10 se muestra el enrutamiento de direcciones pv6.
Rroute YA inet(

Figura 4. 10: Creacin regular de un tnel Broker.

104

Aunque en relacin ala primera simulacin del mecanismo tnel
Broker, resultara sencillo trabajar con gogoCLENT ya que no presenta
muchos procesos como programar.

4.&. ,imuaci"n de mecanismo Dua ,tac@.
Una vez conocidas cada una de las interfaces tanto de la Pila Pv4
como la Pila Pv6, procedemos a configurar la asignacin del
direccionamiento en Pv6ya sea para el Sistema Operativo Windows o
Linux. De esta manera tendramos una direccin vlida paraPv6, ya que
si se activa Pv6 inmediatamente se carga una direccin de hostlocal
(fe,)!!&.&!%%00!0eb0!)--1?%), la cual no nos sirve para tener salida hacia
el nternet.

La solucin es proceder a la asignacin de una direccin vlida
enPv6 configurando de manera manual, siendo esta la manera correcta
para realizar pruebas de configuracin del presente trabajo investigativo,
adicional a la asignacin manual de direcciones Pv6, existe otra forma
dinmica conocida como Dinamic Host Control Protocol versin 6,
(DHCPv6).

Estabecimiento de Dua ,tac@ en MindoJs!
En primer lugar se asignar una direccin Pv6 que sea vlida para
tener una salida directa a nternet, para establecer el transporte de datos
en Dual Stack Pv4 e Pv6, debemos levantar cada una de las dos
interfaces de Pv4 e Pv6 (ver figura 4.11),y posteriormente escribimos un
comando que permita establecer una direccin vlida en Pv6.

Figura 4. 11: Asignacin manual del protocolo de internet versin (Pv6).

105

La figura 4.12 nos muestra la direccin Pv6 esttica asignada
manualmente, cuyo direccionamiento en doble pila >>D-al 5tac9??,
permitir enviar sin inconvenientes el transporte y envo de paquetes en
doble pila ya sea para Pv4 e Pv6, as como tambin la salida hacia el
nternet.

Figura 4. 12: Pv6 asignada manualmente para establecer >>D-al 5tac9??.

Con0iguraci"n de Dua ,tac@ en Linu8!
Ahora para configurar Dual Stack en el Sistema Operativo Linux, se
debe tener activado Pv6, para posteriormente asignarle una direccin
Pv6 esttica a la interfaz, esto se lo consigue de la siguiente manera:
a. Primeramente debemos editar un fichero que corresponda a una
tarjeta de red, pero mediante el siguiente comando:
$i-etc-sysconfig-netor"#scripts-ifcfg#eth).

b. Posteriormente se agregan tres variables:
I'E(INI+ T #es (inicializamos con Pv6 en la tarjeta de red).
I'E(PA2+5C5N1 T no (desactivamos la generacin automtica
en la tarjeta de red para direcciones Pv6).
I'E(ADDR T /,)):)01):)))0:)1)0::)0)/ (asignacin esttica de
una tarjeta de red para direcciones Pv6).

c. Despus guardamos los cambios en un fichero, el cual debe
editarse tal y como se muestra en la figura 4.13.

106

Figura 4. 13: Fichero para >>D-al 5tac9?? en Linux.

d. Finalmente, reiniciamos los servicios de red mediante el
comando22service netor"restart33 y posteriormente digitamos
el comando i0con0ig3 es decir, que la direccin Pv6 se ha
configurado, para lo cual se debe reiniciar la mquina o pc y sin
desaparecer la direccin, ya que sta inmediatamente guardar los
cambios en los registros del sistema operativo Linux.

Ahora que se han configurado los Sistemas Operativos Windows y Linux
respectivamente, a travs del >>D-al 5tac9??donde se tiene el doble
direccionamiento, esto gracias a la aplicacin del mecanismo de transicin
>>D-al 5tac9?? descrito en la propuesta del captulo 3 siendo el objetivo
del presente trabajo investigativo.

En las figuras 4.14 y 4.15 se muestran las capturas de los paquetes de
una red, esto se logr a travs del software 4thereal.

107

Figura 4. 14: Captura del datagrama Pv6.

Figura 4. 15: Estructura del encabezado del datagrama Pv6.

108

Captuo %! Concusiones # Recomendaciones.

%.1. Concusiones.
1. A travs del estado del arte se pudo establecer los fundamentos
tericos necesarios de los protocolos de internet disponibles en
la actualidad y los que a futuro continuarn operativos, en
consecuencia se pueden crear lneas de investigacin acerca
de las redes de comunicaciones de datos.

2. Mediante los mecanismos de transicin para interconexin y
comunicacin, propuestos para la transicin de Pv4 a Pv6
consiste en que las prestadoras de servicio de internet (SPs)
pongan en prctica cualquiera de los mecanismos, y que los
equipos (hardware) sean compatibles con los mismos.

3. A travs de las 3 pruebas desarrolladas se pudo constatar que
de manera interna existen SPs que soportan mecanismos de
transicin de acuerdo a las disposiciones emitidas por el
CONATEL y cuyo control lo realizan de manera conjunta el
MNTEL y la SUPERTEL.

4. Evidentemente el trabajo es difcil para los administradores de
redes o sistemas de las SPs o compaas que van a emplear
los mecanismos de transicin, ya que debern elegir el
mecanismo ms adecuado, la SUPERTEL tiene previsto para
este ao 2013 definir guas de implantacin de los mecanismos
propuestos para determinadas aplicaciones, incluyendo grandes
redes corporativas (SPs), hasta dispositivos mviles y usuarios
domsticos.

5. El presente trabajo investigativo ha servido de mucho para el
personal del Laboratorio de la SUPERTEL, ya que ah ponen en

109

prctica todos los mecanismos de transicin para futuros
controles a las SPs.

6. Con el protocolo Pv6 la red de nternet ser ms rpida, ms
segura y fiable para todos, para acceder a ciertas aplicaciones
en tiempo real. Aunque se puede pensar que la transicin a
Pv6 sea un proceso largo, complejo y muy costoso, pero las
aplicaciones marcarn el ritmo de la transicin.

%.&. Recomendaciones.
1. A partir de los mecanismos de transicin existe un mundo de
posibilidades para experimentar con Pv6 ya sea en movilidad,
seguridad a nivel de red, integracin con otros dispositivos
pad's, tablets y celulares smartphones.

2. Que la Universidad Catlica de Santiago de Guayaquil a travs
de la Facultad de Educacin Tcnica para el Desarrollo y de la
Maestra en Telecomunicaciones, que se involucren ms a
fondo mediante investigaciones que den resultados positivos
para la migracin total del protocolo Pv6, y que puedan invertir
en equipos que permitan desarrollar la parte experimental.

3. Los equipos que se involucran en la transicin deben ser
previamente analizados, para saber cul es ms flexible y
econmico de adquirir, dichos equipos deben utilizar el
protocolo Pv6 antes de ser actualizados y as poder producir
bajas en el rendimiento.

4. Que el MNTEL y SUPERTEL difundan talleres sobre la
transicin de Pv4 a Pv6 a toda la ciudadana a travs de las
Universidades Pblicas y Privadas del Ecuador.

110

/ibiogra0a
Cisco. (2004). #mplementin! #'v6 for &isco #O5 5oftBare. Obtenido de
www.cisco.com

Dunmore, M. (2005). 6net an Pv6 Deployment Guide. En M. Dunmore,
6net an #'v6 Deplo$ment E-ide (pgs. 3-4). Javvin
Technologies nc.Distribution .

Feyrer, H. (24 de 05 de 2001). Onlamp. Obtenido de ntroduction to
PV6. OReilly:
http://onlamp.com/pub/a/onlamp/2001/05/24/ipv6_tutorial.html

Gordo Saez, R. (1998). %ransmisin de #nformacin en #nternet.
Espaa.

Jara, F. (2009). 3st-dio e implementacin de -na red #'v6 en la
6%L5. Valparaso-Chile: Universidad Tcnica Federico Santa
Mara.

Kotal, V. (2005). %esis '@D; 'rinciplesC implementation and transistion
to #'v6 protocol. Praga: Universidad de Karlova.

Lzaro, J., & Miralles, M. (2004). L-ndamentos de %elem1tica. Mxico,
D.F. : Universidad Politcnica de Valencia .

Malone, D., & Niall, M. (2005). #'v6 .etBor9 Administration. O'Reilly.

Moore, K. (2001). DraftG#etfG.!transG6to4GD.5; 6to4 and D.5.

Nordmark, E. (2000). 7L& 2765; 5tateless #'(#&' %ranslation
Al!orit@m *5##%+.

111

Olvera, C., Palet, J., & Vives, A. (2008). Herramientas de %ransicin
#'v6. La Habana: http://www.cuba.ipv6tf.org/talleripv6-
2008/5.pdf.

Palet, J. (Abril de 2007). %@e &@oice; #'v4 30@a-stion or %ransition to
#'v6. Obtenido de The Pv6 Portal:
http://www.ipv6tf.org/pdf/the_choice_ipv4_exhaustion_or_transiti
on_to_ipv6_v4.4.pdf

Pinillos, E. (2003). P versin 6: La nueva generacin P. %4l4matiI-e ,
51-54.

Regis dos Santos, R., Moreiras, A. M., Reis, E., & Soares da Rocha, A.
(2010). &-rso #'v6 b1sico. So Paulo: Antnio Marcos
Moreiras.

Richard Stevens, W. (2011). %&'(#' #ll-strated <ol-me 1; %@e
protocols.Michigan: Addison-Wessley.

Trejo Ramrez, G. (17 de 07 de 2012). 7edes &omp-tacionales.
Obtenido de Slideshare:
http://www.slideshare.net/GabyRamirez13/redes-
computacionales-13269885

Tsirtsis, G., & Srisuresh, P. (2000). 7L& 2766; .etBor9 Address
%ranslation G 'rotocol %ranslation *.A%G'%+.

Tsuchiya, K., Higuchi, H., & Atarashi, Y. (2000). 7L& 2767; D-al Hosts
-sin! t@e 8-mp in t@e 5tac9 tec@niI-e *8#5+.

UPF. (17 de 09 de 2012). 6niversitat 'ompe- Labra G 8arcelona.
Obtenido de http://www.upf.edu/estiu/_pdf/1421t1.pdf

112

Urea Poirier, H., & Rodrguez Martn, J. (17 de 09 de 2012). Eobierno
de &anarias. Obtenido de Consejera de Educacin,
Universidades y Sostenibilidad:
http://www.gobiernodecanarias.org/educacion/conocernos_mejo
r/paginas/ip.htm

Verdejo Alvarez, G. (2000). 3l 'rotocolo #'v6 $ s-s e0tensiones de
se!-ridad #'5ec. Barcelona: UAB.

11

Ane8o A! 'arImetros de Caidad para a pro$isi"n de ,er$icio de
Eaor Agregado <,EA= de Internet.

A continuacin se mostrarn el resumen de los parmetros de calidad
para el SVA de nternet.

R C"digo 'arImetro Eaor 5b6eti$o
1 4.1 Relacin con el cliente. Valor objetivo semestral: R
c
S
2 4.2 Porcentaje de reclamos
generales procedentes.
Valor objetivo mensual: %R
g
2%
Para permisionarios con menos de
50 clientes conmutados o con
menos de 25 cuentas dedicadas, el
valor objeto mensual: R
c
4%
3 4.3 Tiempo mximo de resolucin de
reclamos generales.
Valor objetivo mensual: mximo 7
das para el 98% de reclamos.
4 4.4 Porcentaje de reclamos de
facturacin.
]
2%
5 4.5 Tiempo promedio de reparacin
de averas efectivas.
Valor objetivo mensual: Iro
24 oros
6 4.6 Porcentaje de mdems
utilizados.
Valor objetivo mensual:
%H
utIzudos
1uu (durante el 98%
del da).
7 4.7 Porcentaje de reclamos por la
capacidad del canal de acceso
contratado por el cliente.
c
2%

114

Ane8o /! 'oticas Regionaes I'$( Y CI+EL

5RGANIWACI5N DE L5, E,+AD5, A*ERICAN5,
5RGANIWA+I5N 51 A*ERICAN ,+A+E,

Comisi"n Interamericana de +eecomunicaciones
InterCAmerican +eecommunicationCommission

VV RE2NI\N DEL C5*I+] C5N,2L+IE5
'ER*ANEN+E I! +ELEC5*2NICACI5NE,;
+ECN5L5GIA, DE LA IN15R*ACI5N ^ LA
C5*2NICACI5N
De 1( a 1- de ma#o de &.1&
1ueno# ,ire#. ,rgentina
5EA;,er.L;VEII.4.1
CC'.IC+IC;doc. &(.);1&
1) ma#o &.1&
5rigina! espa:o

'5L+ICA, REGI5NALE, 'ARA LA AD5'CI\N ^ C5EVI,+ENCIA I'$4
e I'$( 'ARA L5, 'AI,E, *IE*/R5, DE CI+EL

<'unto de temario! 3.1.&=
<Documento presentado por a deegaci"n de Ecuador=

Introducci"n

La implantacin de normas conjuntas y estandarizadas en el mbito de la Adopcin
de Pv6, se vuelve imperiosa debido a la necesidad de unificacin de criterios para el
acceso a nternet en la regin y desarrollo de nuevas tecnologas.

El tratamiento de polticas para el impulso de la nueva versin del protocolo de
nternet, ser un envin para la generacin de la sociedad de la informacin,
aprovechando las capacidades brindadas para el desarrollo de nuevas plataformas o
contenidos estables y seguros.

La transicin hacia Pv6, ser una oportunidad para los Estados de promover nuevas
formas de negocios para el sector empresarial, basados en la generacin de
conocimiento y apropiacin de tecnologas disponibles para la comunicacin y
aprendizaje sobre nternet.

Es necesario el emprendimiento de metas y estrategias conjuntas para la Adopcin
del nuevo protocolo de nternet (Pv6), de forma que se promueva una correcta
coexistencia y transicin y se impulse el desarrollo regional de nuevas plataformas y
contenidos que originen el adelanto econmico y la promocin del conocimiento.

Los planes de despliegue de Banda Ancha no podrn cumplirse si no se toman
medidas urgentes para garantizar que la administracin pblica, proveedores de
contenidos, SPs y la industria en general, tomen conciencia de las importancia de
este cambio tecnolgico y se ejecuten las acciones pertinentes, de tal forma que los
usuarios puedan comenzar a utilizar Pv6 de un modo satisfactorio, sin costos
adicionales y de forma transparente, caso contrario la Regin corre el riego de una
nueva "Brecha Digital.

115

En tal sentido se propone el siguiente grupo de medidas a adoptarse con el fin de ir
implementando un proceso ptimo de implantacin del nuevo protocolo:
'R5^EC+5 DE REC5*ENDACI5N
CC'.I;REC. VVV <VVC1&=

'5L+ICA, REGI5NALE, 'ARA LA AD5'CI\N ^ C5EVI,+ENCIA
I'$4CI'$( 'ARA L5, 'AI,E, *IE*/R5, DE CI+EL

La XX Reunin del Comit Consultivo Permanente :
Telecomunicaciones/Tecnologas de la nformacin y la Comunicacin (CCP.),

C5N,IDERAND5!

a. Que es necesario el diseo e implantacin de polticas que permitan la estabilidad
y el correcto funcionamiento de la red de nternet;

b. Que dentro del Plan de Accin eLAC 2015, se insta a los pases miembros a
colaborar y trabajar en forma coordinada con todos los actores regionales,
incluidos los sectores acadmico y comercial, la comunidad tcnica y las
organizaciones que participan en el tema, como el Registro de Direcciones de
nternet para Amrica Latina y Caribe (LACNC) y la Sociedad nternet (SOC),
entre otras, para que la regin logre un amplio despliegue del Protocolo de
nternet versin 6 (Pv6), as mismo hace un llamado a implementar con brevedad
planes nacionales que permitan acceder a los portales de servicios pblicos
gubernamentales de los pases de la regin a travs de Pv6 y que las redes
estatales trabajen de forma nativa con Pv6, en coexistencia con Pv4;

c. Que en febrero de 2011 el Registro de Direcciones de nternet de Amrica Latina
y el Caribe, LACNC, comunic que el stock central de direcciones Pv4
administrado por la ANA (nternet Assigned Numbers Authority) se agot
definitivamente, pues fueron entregados los ltimos bloques disponibles de
direcciones Pv4 a cada uno de los cinco Registros Regionales de nternet (RR)
en todo el mundo y a partir de esta fecha nicamente se podr acceder al stock
con el que cuenta LACNC,

REC5N5CIEND5!

a. Que es necesario que los Estados Miembros de CTEL, dentro de sus
competencias, coordinen con las entidades del sector pblico y privado la
coexistencia de los protocolos Pv4 e Pv6 as como la transicin futura a Pv6;

b. Que la implementacin de programas de transicin Pv4-Pv6, mantendr la
inclusin y cohesin tecnolgica de los diversos actores (Gobierno, Academia,
Proveedores, Usuarios, etc.);

c. Que la CTEL, a travs del CCP. recomend que las administraciones difundan
entre los proveedores de servicios, equipamiento, software, aplicaciones y
servicios para las redes, instituciones educativas, de investigacin, desarrollo
tecnolgico y usuarias de nternet, la informacin relacionada con la necesidad de
prepararse para la convivencia entre Pv4 e Pv6 y su posterior adopcin
definitiva,

RECOMIENDA:

1. Que los Estados Miembros de CTEL promuevan la construccin participativa e
inclusiva de guas de coexistencia y transicin Pv4-Pv6 involucrando a todos los

116

actores del ecosistema de nternet, .a travs de la constitucin de fuerzas de
trabajo (Task Force).

2. Que los Estados Miembros de CTEL realicen un diagnstico de la situacin
actual de adopcin de Pv6 en cada pas y sobre esa lnea base estructuren
lineamientos y desarrollo de polticas vinculadas con el nuevo protocolo de
nternet Pv6.

3. Que las nstituciones y Organismos del Sector Pblico de los Estados Miembros,
implementen en sus sitios web y plataformas de servicios electrnicos, el soporte
y compatibilidad con el protocolo Pv6 de manera coexistente con el protocolo
Pv4, con la finalidad de generar trfico Pv6 a nivel nacional y permitir que dichos
recursos pblicos sigan siendo visibles desde el resto del mundo, esta medida
adems propender al desarrollo del Gobierno en lnea de la nueva era.

4. Que los Estados Miembros de CTEL desarrollen marcos referenciales para
compras nacionales de Pv6 considerando aspectos como: Equipamiento,
software, servicios-aplicaciones, formacin de capital humano y usuarios.

5. Que se implementen los procedimientos administrativos o normativos, para
garantizar el correcto funcionamiento del protocolo Pv6 en los ccTLD de cada
pas miembro de CTEL, sin incremento de costos para los usuarios.

6. Que bajo el esquema de "dar ejemplo, los Entes de Regulacin y Rectora de
Telecomunicaciones implementen proyectos piloto sobre Pv6 en sus sitios Web y
plataformas de servicio a fin de incentivar al resto de organismos e instituciones
pblicas a implementar el nuevo protocolo.

7. Que los Estados Miembros consideren la posibilidad de elaborar Estrategias
Nacionales de Pv6, con el fin de garantizar una asignacin suficiente y adecuada
de direcciones Pv6 a cada Estado por parte de los RR.

8. Que los Estados Miembros estimulen la implementacin Pv6 en el sector privado
(necesidad de comunicarse con el gobierno).

9. Que se ejecute las acciones y procedimientos administrativos y normativos
necesarios con el fin de que los Proveedores de Servicio de nternet SPs y
Carriers, permitan en sus redes, plataformas y servicios la coexistencia de Pv4 -
Pv6.

10. Que los Estados Miembros de CTEL ejecuten las acciones necesarias con el fin
de que los Proveedores de Servicios de nternet (SPs), establezcan sus planes
de direccionamiento, y en funcin de los mismos, inicien los trmites para la
solicitud de recursos de direccionamiento (direcciones P) Pv6.

11. Que los Estados Miembros de CTEL realicen campaas de sensibilizacin,
difusin, capacitacin y formacin de Pv6.

12. Que los Estados Miembros impulsen y financien proyectos tecnolgicos con
soporte Pv6.

13. Que se propenda a la adopcin de Pv6 en redes de investigacin y educacin.

ENCARGA:

1. Al Secretario Ejecutivo de la CTEL a comunicar esta Recomendacin a las
delegaciones de los Estados Miembros de la CTEL con el objeto de lograr que la

117

mayora de pases adopten las medidas propuestas, lo cual permitir fomentar la
implementacin de polticas conjuntas para la adopcin de Pv6.

2. Al Secretario Ejecutivo de la CTEL para que transmita al Comit Directivo
Permanente de la CTEL (COM/CTEL) esta Recomendacin para su conocimiento.

T Ucsg Pos Mtel 5

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

T Ucsg Pos Mtel 5

Enviado por

Direitos autorais:

Formatos disponíveis

SSTEMA DE POSGRADO

Recuperado el 12 !unio 2012 online http://www.ip"6.e#/e#$%&/'a(#/)agina#/tecnica#.a#p*

Você também pode gostar