Professional Documents
Culture Documents
Dialnet CaracterizacionDeIPv6 4239524
Dialnet CaracterizacionDeIPv6 4239524
Caracterización de IPv6
IPv6 Characterization
RESUMEN ABSTRACT
The present paper attempts to survey the cu-
un recuento de lo que es el protocolo IPv6; des- rrent state of the network protocol called IPv6;
de la evolución de IPv4, que motivó el diseño starting from the evolution of IPv4 (which mo-
de nuevas características, hasta los detalles que tivated the design of new features) to the de-
componen la nueva versión del protocolo de In- tails that are comprised in the new version of
ternet. En las secciones principales del artículo the Internet Protocol. The main sections explain
se explican los inconvenientes de IPv4 que se the drawbacks of IPv4 that can be overcome by
resuelven al implementar IPv6, destacando los implementing IPv6, highlighting aspects such as
aspectos de seguridad, movilidad y calidad de security, mobility, and Quality of Service (QoS).
servicio (QoS).
Servicio de Red: el protocolo debe permitir que Host: un nodo que puede enviar y recibir pa-
la red asocie los paquetes a las clases particulares quetes, pero no paquetes de reenvío para otros
del servicio y provea de ellas los servicios especi- nodos.
Link (Enlace): una facilidad de comunicación
Movilidad: el protocolo debe apoyar los hosts, las o medio sobre el cual los nodos pueden comu-
redes, y los internetworks móviles. nicarse en la capa de enlace, es decir, la capa
inmediatamente inferior a IPv6. Ejemplos de
Protocolo de control: el protocolo debe incluir la ello son: Ethernets (simple o un puente), Point-
ayuda elemental para soportar y probar las redes to-Point Protocol (PPP), X.25, Frame Relay, o
para eliminar los errores. modo de transferencia asíncrona (ATM) las re-
des, y de tres capas (o superior) túneles, como
Redes privadas: IPng debe permitir que los usua- los túneles sobre IPv4 o IPv6.
rios construyan internetworks privados encima de
la infraestructura básica del Internet, apoyando Link MTU (MTU del Enlace): la unidad de
internetworks basados en IP y basados en no-IP. transmisión máxima (MTU), es decir, tamaño
de paquete en octetos, que puede ser transmitida
sobre un enlace.
4. TERMINOLOGÍA BÁSICA
Path MTU (MTU de Camino): el mínimo víncu-
7 lo MTU de todos los eslabones de una ruta entre
entender correctamente la referencia al Protocolo un nodo fuente y un nodo destino.
IPv6, RFC 2460 [20]:
Upper Layer (Capa Superior): una capa de pro-
? 8M~ Y tocolo inmediatamente encima IPv6. Ejemplos
una interfaz de capa o un conjunto de interfaces de ello son los protocolos de transporte como
# ! $ es de los bits de orden superior De igual forma, el RFC 4291 también describe
8 Y! 8 ^ Z 7 ^
'! ! - de red son análogos, pero no equivalentes a la
8 { X máscara de subred en IPv4. No existen máscaras
Direcciones IPv6. de subred en IPv6, la notación de / es usada para
"
^ ^ ~
# ?M~ -
lace de un sitio. El ID de subred es asignado por
2001:0db8:9095:02e5:0216:cbff:feb2:7474/32
el administrador local del sitio, un sitio puede
"
7 ^
utiliza como un indicador para la red en la que
$} " 7 _ "
se tienen varios host en su interior.
el administrador local para relocalizar el ID de su-
bred y el ID de host. Nuevamente, es importante
# % (ID host) es un identi- tener claro que los ID de host son únicos y sirven
* 7
Y * 5 muestra dicha situación:
7 * -
8 Y ^ ! Las subredes dentro de una organización a menu-
" ' ^ " ? M! ^
64 bits para la asignación a las interfaces de host. 8. ALCANCE DE LAS DIRECCIONES IPV6
El ID de host debe seguir el formato suministrado
? M1. La Cada interfaz puede tener naturalmente más de
"8 - 8! + #$%!
Y #${%~ ~
7 { * -
Link Local: es la dirección local del interfaz con
ciones IPv6:
alcance de redes (LAN - Network Area Local),
1 IEEE EUI-64, Guidelines for 64-Bit Global Identier se puede designar o también obtenerla automá-
(EUI-64) Registration Authority. ticamente componiéndose esta dirección con la
Los protocolos de capa más alta no deben asu- El campo de Siguiente Cabecera (Next Header
" X * Field): el campo Next Header tiene 8 bits de lon-
un paquete recibido son los mismos valores que "
fueron originalmente transmitidos. En otras pala- siguiente del encabezado de IPv6. Este campo
bras, un nodo intermediario puede ser permitido usa los mismos valores que el campo Protocol
" ?' " " M " X * Y O
Class en tránsito. ejemplos:
Modo túnel: una plataforma, o pasarela, encapsula ción opcional. Su ubicación se puede ver en la
el paquete original en otro paquete. Con ello se ci- OO
fra o autentica el paquete original completo, pero
se necesita de una plataforma que realice el túnel. ESP (Encapsulating Security Payload): además
^ -
Además, IPsec tiene dos modos o protocolos de @ 8 -
transferencia, que a su vez pueden funcionar en gura 12.
modo túnel o transporte:
En la práctica, el uso de IPsec es escaso debido,
AH (Authentication Header): proporciona auten- sobre todo, a la falta de un mecanismo generali-
ticación, integridad y un servicio de anti-repeti- zado y global de intercambio de claves. Por esta
La solución futura para el problema anterior pue- Funcionamiento general: un nodo móvil siem-
de que se base en mecanismos externos como cer- pre pretenderá ser accesible desde su dirección
&@ principal, sin importar si éste se encuentra fí-
DNSSEC2. sicamente conectado al vínculo principal o ya
+ ^
[49]. La dirección principal o home address es,
11. MOVILIDAD EN IPV6 según lo expresado en [50], la dirección IP que
le corresponde al nodo en el ámbito de su vín-
Concepto: se entiende por movilidad a la capaci- culo principal. Mientras el nodo se encuentra en
dad para que un nodo de la red mantenga la mis- su vínculo principal, los paquetes destinados a
ma dirección IP, a pesar de que éste se desplace esa dirección principal son ruteados utilizando
físicamente a otra área [46]. Es decir que, sin los mecanismos estándares de ruteo de Internet.
importar su ubicación, este pueda seguir sien- Cuando el nodo se encuentra físicamente conec-
do accesible a través de la misma dirección IP. tado a otro vínculo aún es accesible, por lo que
Sin esta capacidad, los paquetes destinados a un se denomina una care-of-address (sin traducir
nodo móvil no estarán posibilitados para llegar de [50]). La cual es una dirección IP asociada al
a destino mientras el nodo móvil se encuentre 8 ^ "
alejado de su vínculo principal (home link). Un vínculo externo. Un nodo móvil puede, llegado
nodo móvil bien podría seguir manteniendo la el caso, ser accedido por más de una care-of-ad-
comunicación al ir cambiando su dirección IP dress. El nodo móvil puede obtener la dirección
cada vez que salta de proveedor a proveedor, en el vínculo externo mediante los mecanismos
pero esto trae aparejado el problema de ir per- habituales de IPv6.
diendo la conexión en las capas de transporte y
superiores. Por eso, es necesario el estudio y de- El proceso de asociación entre una dirección
sarrollo de protocolos que permitan movilidad de tipo care-of-address de un nodo móvil y su
a lo largo de varios tipos de redes, en distintas dirección principal o home address se conoce
+ + #% #% como binding. Cuando el nodo móvil se encuen-
tra alejado, éste registra su dirección de tipo ca-
Uso en IPv6: el soporte de movilidad es una ca- re-of-address en el router de su vínculo principal
racterística muy tenida en cuenta en la imple- (home-agent según [50]). Cualquier otro nodo
mentación de IPv6, ya que se espera que una que desee comunicarse con el nodo móvil tiene
gran parte de la población requiera de servicios dos maneras para establecer un vínculo con el
de movilidad durante el periodo de vida de IPv6. nodo móvil: la primera se menciona en [50], co-
7 8 - nocida como túnel bidireccional, no requiere so-
Y + porte de movilidad IPv6 por parte del nodo que
Z\ ${{|~ Mobility Support in IPv6, además de desee comunicarse (correspondent node). Los
paquetes enviados por el correspondent node
2 Domain Name System Security Extensions: Dis- son enviados al router en el vínculo principal del
ponible en: https://www.iana.org/dnssec nodo móvil. Y es este router (home-agent según
REFERENCIAS
[1] M. Del Rey, Internet Protocol, California: [6] P. A. Castillo Valdivieso, Interoperabilidad
IETF. 1981, RFC 791. de Redes Heterogeneas de Computadores,
2005.
[2] B. A. Forouzan, Transmisión de Datos y
Redes de Computadores, Madrid-España : [7] E. F. Pinillos T, “Ip versión 6: La nueva Ge-
Mac Graw Hill, 2007. neración IP”, Revista Electrónica de Estu-
dios Telemáticos, pp. 50-57. 2008.
#$% ! Mundo IP. Madrid - España:
Ediciones Nowtilus, 2004. [8] Frankel, Sheila, et al., Guidelines for the Se-
cure Deploymen of IPv6, Washington D.C.:
[4] A.Tanenbaum, Redes de Computadoras, U.S. Departament of Commerce, 2010.
~ Y W ! }$
[9] G. Huston, Next Steps for the IP QoS Ar-
[5] J. Rodríguez Albornoz y R. Guerra Díaz, chitecture, California: IETF, 2000. RFC
Evaluación y Comparación de los Proto- 2990.
colos de Internet IPv4 e IPv6 en una Red
Experimental WDM, Valparaíso - España: [10] S. Kent and R. Atkinson, Security Archi-
Publicaciones Universidad Técnica Federi- tecture for the Internet Protocol, Califor-
co Santa María, 2005. nia: IETF, 1998. RFC 2401.
#O$% WG ! The SSL Protocol, Cali- [26] J. Curran, An Internet Transition Plan, Cal-
* ~ $! O__ ifornia: IETF, 2008, RFC 5211.
[14] E. Rescorla, The Secure HyperText Trans- [27] Euro6IX, Ipv6: Legal Aspects of the new
fer Protocol, California: IETF, 1999, RFC Internet Protocol, Madrid: Euro6IX, 2005.
2660.
[28] R. Gilligan, Transition Mechanisms for
[15] A. Ghiselli, INFN Requirements for an IPv6 Hosts and Routers, California: IETF,
IPng, California: IETF, 1994, RFC 1676. }! Z\ }_$
[16] M. Vecchi, IPng Requirements: A Cable [29] J. Arkko, Guidelines for Using IPv6 Tran-
Television Industry Viewpoint, California: sition Mechanisms, California: IETF, 2010.
IETF, 1994, RFC 1686. Draft-arkko-ipv6-transition-guidelines-01.
[17] D. Santana Yunes, IPv6: Nueva Genera- #$% ^G! Security On Demand for Mobile
ción Protocolo de Internet, Santo Domin- IPv6 and Dual-stack Mobile IPv6, Califor-
go: Universidad Nacional Pedro Henríquez nia: IETF, 2010, Draft-bajko-mext-sod-00.
Ureña, 2004.
#$O% X ! Dual-Stack Mobile IPv4, Cali-
[18] G. Van de Velde, IPv6 Unicast Address fornia: IETF, 2009. RFC 5454.
Assignment Considerations, California :
X\! }! Z\ |${| #$}% Z ! Using IPsec to Secure IPv6-
in-IPv4 Tunnels, California: IETF, 2007.
[19] H. Holbrook, ' RFC 4891.
IP, California: IETF, 2006. RFC 4607.
#$$% ! IPv6 Tunnel Broker with the
[20] S. Deering, Internet Protocol, version 6 Tunnel Setup Protocol (TSP), California:
*+/0 S.l.: IETF, 1998, RFC IETF, 2010, RFC 5572.
2460.
#$% \ G ! IPv4 and IPv6 Greynets, California:
[21] J. Postel, User Datagram Protocol, Cali- IETF, 2010, Draft-baker-v6ops-greynet-02.
fornia: IETF, 1980. RFC 768.
#$|% @ ! Reserved IPv6 Interface Iden-
[22] Internet Control Message ProtocoL, Cali- * ~ X\! }_! Z\ ||$
fornia: IETF, 1981. RFC 792.
#$% Z W ! @ ! IP Version 6 Ad-
#}$% '! OSPF Version 2, California: IETF, dressing Architecture, S.l.: IEFT, 2006,
O__ Z\ }$} RFC 4291.