Medicin del rendimiento de LDAP en un esquema de

transicin IPv6 a IPv4, usando el mecanismo de double

stack 1

Rafael Espinosa1, Axel Ernesto Moreno-Cervantes2 y Guillermo Morales-Luna3

1
CINVESTAV-IPN, SEES/Sistemas VLSI, Av. Instituto Politcnico Nacional # 2508,
Mxico, D.F
espinosa@math.cinvestav.mx
2
CINVESTAV-IPN, Seccin de Computacin, Av. Instituto Politcnico Nacional # 2508
Mxico, D.F.
amoreno@computacion.cs.cinvestav.mx
3
CINVESTAV-IPN, Seccin de Computacin, Av. Instituto Politcnico Nacional # 2508
Mxico, D.F.
gmorales@cs.cinvestav.mx

Resumen. Este trabajo reporta los resultados que se obtuvieron de las

mediciones realizadas al servicio de directorios Lightweight Directory Access
Protocol en un escenario de red TCP/IP con mecanismo de transicin double
stack 6to4. El servidor de LDAP realiz la emisin de certificados digitales por
medio de las operaciones de bsqueda, lectura y modificacin y se interactu
con ste a travs de clientes LDAP instalados en Windows XP y en Solaris. Se
midi el desempeo de las consultas y las modificaciones en el servidor LDAP
a travs de la red de prueba 6to4, tanto en forma local como a travs de la
interaccin del tunnel broker de Freenet6. Las mismas pruebas se corrieron en
un ambiente IPv4. Las mediciones obtenidas nos permitieron comparar el
desempeo de LDAP en IPv6 como en IPv4.

1 Introduccin

El mtodo actual de asignacin de direcciones IPv4 es ineficiente ya que ha resultado

que casi tres cuartas partes del total de direcciones son propiedad de grandes
organizaciones tales como IBM y ATT. El American Registry for Internet Number
(ARIN) establece que el total de la clase A, el 62% de la clase B y el 37% de las
direcciones C ya han sido asignadas desde 1996. El grupo de trabajo IETF NGTrans
ha previsto, considerando tendencias actuales, que las direcciones IPv4 sern agotadas
aproximadamente en el ao 2008.

1 Trabajo realizado con patrocinio parcial del CONACYT de Mxico, dentro del proyecto
34528-A.
 IPv6, llamado tambin Internet Protocol Next Generation (IPng), ha sido
desarrollado para remplazar IPv4 gradualmente, conservando la capacidad para
interoperar con IPv4. Las direcciones de 128 bits de longitud sern suficientes para
resolver la disponibilidad de direcciones IP. Conforme IPv6 aumenta su presencia, los
sitios IPv4 actuales y sus aplicaciones empezarn a quedar aislados, sin embargo, la
transicin tomar tiempo.

2 Un enfoque sobre IPv6

La funcin de enrutamiento determina la posible trayectoria que recorrern los
datagramas en la red. Las dorsales de Internet deben tener suficiente informacin de
las redes disponibles en el mundo para que los paquetes se enven a su destino
correcto. La arquitectura de IPv4 requiere de grandes tablas de enrutamiento para
mantener actualizada la informacin de las rutas hacia cada una de las redes activas.
El aumento del trfico IP y de los identificadores de red en algn momento va a
saturar las tablas de enrutamiento. La implantacin de CIDR (Classless Inter Domain
Routing) [RFC 1518, RFC 1519] de momento ha retrasado los problemas con el
espacio de direcciones IP y las tablas de enrutamiento. CIDR usa un mtodo que
utiliza un prefijo IP y no requiere de una clase basada en enrutamiento.
La fragmentacin se realiza de acuerdo al ancho de banda del enlace fsico.
Adems, el tamao del paquete se basa en el MTU (Maximum Transfer Unit) y puede
variar segn avance al pasar por cada uno de los routers de la red. La fragmentacin
ocurre continuamente si los MTU subsecuentes difieren del valor inicial. Un solo
paquete perdido origina la retransmisin del paquete completo, lo que resulta en un
bajo promedio de transferencia. En IPv6, el enrutador emisor determina el MTU ms
pequeo de la trayectoria y fragmenta los paquetes. As, la fragmentacin y el
reensamble se realizan slo en el nodo origen y en el destino respectivamente. Los
encabezados de extensin de IPv6 llevan la informacin sobre la fragmentacin, la
cual no es recalculada por los enrutadores intermedios.
IPv4 tiene que calcular los checksums en cada uno de los enrutadores presentes en
la trayectoria, siendo un proceso redundante. Las capas superiores como la de TCP
enva otros checksums en los datagramas salientes, y no es necesario calcular los
checksums de la capa de IP, esta funcin ha sido eliminada en IPv6. El trfico
multicasting para aplicaciones multimedia se ha incrementando, el cual se administra
por medio de la clase D de direcciones IPv4, a travs de la dorsal virtual MBONE.
IPv6 elimina la necesidad de tneles mltiples al incorporar multicast en su
arquitectura.
IPv6 incorpora conectividad a usuarios mviles de Internet, as como
caractersticas de seguridad y enrutamiento: La auto configuracin de direcciones de
red para nodos nuevos que se conectan en la red, el desarrollo de ARP, RARP,
DHCPv6 y el soporte a direcciones multicasting y anycasting, haciendo posible plug
and play en IPv6, ests funciones no existen en la arquitectura de IPv4.
 IPv6 introduce IPSec (IP Security) con autenticacin de encabezado (AH) y el
encabezado de encapsulamiento de seguridad (ESP) que proporcionan integridad,
confidencialidad y seguridad en la red. La introduccin del campo de prioridad y de
control de flujo en el encabezado de IPv6 establece calidad de servicio en el trafico
IP. El IETF ha definido el Simple Internet Transition Mechanism que permite la
interoperabilidad entre IPv6 e IPv4 en nodos, actualizaciones incrementales de nodos,
direccionamiento simple para coexistencia de nodos IP y costos mnimos.

&OLHQWHV
&OLHQWHV ,3Y
5RXWHU
,3Y
5RXW HU ,3Y
,3Y

5HG ,3Y
)DVW
(WKHUQHW
)DVW
(WKHUQHW
7~QHO
,3Y RYHU7~QHO
,3Y
,3Y RYHU,3Y
&RQYHUVLyQ
&RQYHUVLyQ ,3Y ,3Y '16
' 16 ,3Y ,3Y
5HG ,3Y
5HG ,3Y GRO
H VW
DFN ,3
GRO
H VW
DFN ,3

Fig. 1. Coexistencia de double stack, tneles y mecanismos de traduccin

interconectando redes IPv6 e IPv4

3 Mecanismos de transicin para IPv6 e IPv4

El IETF tiene un grupo de trabajo llamado, NGTrans (Next Generation Transition)

para administrar la transicin [RFC 1933, RFC 2185]. Este grupo sugiri los
mecanismos que se han implementado, probado y optimizado por ingenieros,
programadores y compaas. Existen tres mecanismos bsicos que han sido
planteados: double stack IP, tneles IPv6-over-IPv4 y traducciones de encabezado y
de protocolo. Estos mecanismos facilitan la conectividad de las redes IPv6 a una
infraestructura IPv4.

3.1 Double stack IP

El mecanismo ms simple para obtener interoperabilidad entre diferentes versiones

de IP es teniendo ambas versiones corriendo en un mismo sistema [RFC 1933]. Esto
permite que la misma mquina maneje dos tipos de trfico. Los paquetes pueden usar
direcciones de IPv4 entre clientes IPv4, direcciones nativas IPv6 o direcciones IPv4 -
compatibles-IPv6 entre los clientes IPv6, o clientes IPv4 y direcciones IPv4 -
transformadas-a-IPv6 entre clientes IPv4.
3.2 Tneles (IPv6 sobre IPv4)

Este mecanismo permite a implementaciones iniciales de IPv6 utilizar la

infraestructura existente sin hacer cambios a los dispositivos de red IPv4. Un ruteador
en la frontera de la red encapsula paquetes IPv6 sobre un paquete IPv4 y lo enva a
travs de una red de IPv4, siendo transparente a la red. El ruteador que se encuentra
en la frontera de otra red, lo desencapsular y lo enrutar al nodo IPv6 destino
correcto.

3.3 Traduccin

La coexistencia entre IPv4 e IPv6 requiere de algn nivel de traduccin entre

ambos protocolos en el nodo o en el enrutador, o en los nodos de stack doble,
sabiendo de antemano cual protocolo usa la aplicacin. Diversos mecanismos de
traduccin de protocolos estn bajo consideracin por el grupo de trabajo de la IETF
NGTrans:
Network Address Translation-Protocol Translation (NAT-PT)
TCP-UDP Relay
Bump-in-the-Stack (BIS)
Dual Stack Transition Mechanism (DSTM)
SOCKS-Based Gateway

4 X.500

X.500, es el estndar OSI que define el servicio de directorios, que incluye un

modelo de informacin, un espacio de nombres, un modelo funcional, un esquema de
autenticacin, y un modelo operacional distribuido. Tambin define el Directory
Access Protocol el cual es utilizado para acceder al directorio. DAP es
significativamente ms complicado que la mayora de las implementaciones que
prevalecen de TCP/IP, adems, requiere de ms cdigo y necesita ms recursos para
correr. El tamao y la complejidad de DAP son una limitacin para correrlo en
computadoras Macintosh y PC, donde TCP/IP con frecuencia forma parte del sistema
operativo. Cuando se usan las implementaciones de DAP, por lo general requieren de
un proceso de optimizacin, lo que ha limitado su aceptacin.

4.1 LDAP

El Lightweight Directory Access Protocol (LDAP) fue diseado para remover parte
de la carga excesiva del acceso de X.500 desde los clientes del directorio,
obtenindose un servicio de directorios que corre sobre TCP/IP u otro transporte,
adems, existen diversas versiones del directorio para diversas plataformas y
aplicaciones de cmputo. Al protocolo se le simplificaron muchas operaciones de
X.500, retirando caractersticas poco usadas y emulando algunas operaciones con
otras. LDAP usa una codificacin simple para cadenas de caracteres para la mayora
de los atributos, dando como resultado un mtodo de acceso eficiente para el
directorio de acceso X.500.
Entre las caractersticas importantes de LDAP, se tienen las siguientes: soporta el
modelo cliente-servidor; organiza la informacin de modo jerrquico usando
directorios; propaga sus directorios a otros servidores LDAP geogrficamente
dispersos; tiene un API de programacin estable; utiliza diversos esquemas de bases
de datos, los cuales trabajan como procesos backend, para el almacenamiento, la
consulta y la actualizacin de su propia informacin.

5 Medicin del rendimiento de LDAP en IPv4 e IPv6

Ya se ha evaluado el rendimiento de IPv6, realizando pruebas con herramientas

como ftp [12], ping [13], en escenarios de conectividad aislados usando el sistema
operativo FreeBSD. Tambin, se valor el desempeo de IPv6 en Windows 2000 y
Solaris [5], midiendo el desempeo del envi de pequeos mensajes tanto en TCP
como en UDP por medio de diversas mtricas.
En nuestro caso, las mediciones se realizan tanto en forma local a travs de nuestra
red local 6to4 y por medio del tnel broker de IPv6 Freenet6, usando los sistemas
operativos Windows XP y Solaris 9 y su respectivo cliente LDAP, interactuando con
el servidor de directorios LDAP instalado sobre el sistema operativo Linux 8.0.

5.1 Configuracin de la red de pruebas

Se usaron dos computadoras personales con procesador Pentium 4 a 1.4Ghz con

256Mbytes de memoria RAM y un disco de 80Gbytes, as como una estacin de
trabajo SUN con procesador UltraSparc ii con 512Mbytes de memoria RAM y un
disco de 20Gbytes. En una computadora personal se instal el sistema operativo
Linux 8.0 y el mdulo que configura el stack de transicin IPv6 -over-IPv4, as como
el servidor de directorios OpenLDAP 2.0.27, as como JDK. Los clientes de LDAP
soportan el mecanismo de stack doble, y se instalaron en la computadora personal con
Windows XP, en el caso de la estacin de trabajo SUN ULTRA 10 se instalo el
sistema operativo Solaris 9 y el mdulo de SSL cliente, as como el backend para la
base de datos usada por OpenLDAP, Por medio de un switch 3Com FastEthernet de
100 Mbps se conectan las computadoras a la red local 6to4, adems, est tiene acceso
a Internet a travs del enrutador Cisco 2600.
El servicio de tnnel broker permite que las aplicaciones IPv6 en un sistema
remoto de stack doble o un sistema IPv6 conectado a un enrutador de doble stack,
acceda una dorsal IPv6 a travs de los tneles 6to4, el cual automticamente
administra la solicitud del tnel y su configuracin. Para las evaluaciones que se
realizaron, se obtuvo el acceso a los servicios de Freenet6, se registr una direccin
IPv4 vlida de nuestra red en la pgina web del proveedor de servicios. . En la
computadora con Linux se instala el script que establece el tnel hacia la red IPv6 y
asigna una direccin IPv6 completa para nuestro servidor. El ISP administra la
creacin y la remocin del tnel 6to4 del servidor de tneles de Freenet6. Un
enrutador con double stack est conectado a la red IPv6 tal como se muestra en la
figura 2. La limitante de Freenet6 es que al usar este servicio, el servidor o el
enrutador est aceptando un cambio de configuracin desde un servidor remoto, lo
cual tiene potenciales implicaciones de seguridad.

Fig. 2. Arquitectura de la red de prueba Zeta usando el mecanismo de dual stack y el tunnel
broker de Freenet6

6 Metodologa de las pruebas

Las mtricas que se usaron para valorar el rendimiento de LDAP usando el

mecanismo de transicin 6to4 usando direccionamiento IP global y local, se basa en
el desempeo de las operaciones LDAP bsicas, como son: bsqueda, modificacin,
insercin, borrado y comparacin de entradas en el directorio. El programa de prueba
se desarrollo en Java haciendo uso de las clases JNDI para acceso a servicios de
directorio, el cual tiene los siguientes parmetros:
30 hilos simulando 30 clientes LDAP simultneamente.
Cada cliente genera desde 100 hasta 1000 transacciones sobre el directorio
Tipo de transacciones realizadas:
Consultas
Actualizacin de entradas
Tipo de direcciones de red utilizadas:
IPv4
IPv6 locales
IPv6 globales
 La diferencia entre las direcciones IPv6 locales e IPv6 globales es que las
direcciones IPv6 locales son slo vlidas dentro del mismo segmento de red, es decir,
dentro de la misma red local, en cambio, las direcciones IPv6 globales son
direcciones de red que son enrutadas fuera de la red local a travs del tnel broker de
Freenet6.

6.1 Resultados obtenidos

La implementacin de double stack que usamos tiene modificaciones en la capa de

TCP, donde la longitud de la direccin ha cambiado de 32 bits a 128 bits y el clculo
del checksum ha sido eliminado en la capa de IP. En la capa de TCP el campo de
datos tiene una longitud de 1460 bytes en IPv4 y de 1440 en IPv6. Esta diferencia en
la longitud del campo de datos en las dos versiones de IP implica una degradacin de
1.37% en el desempeo del protocolo. Si consideramos que el envi y la recepcin de
un buffer de IPv6 de 8192 bytes comparado con los 16384 bytes en IPv4. Esto parece
haber disminuido la eficiencia del envi y recepcin de las computadoras usadas en la
evaluacin. Razn por la cual protocolos mltiples que estn corriendo en el
mecanismo de transicin 6to4 pueden degradar la eficiencia de LDAP. Es difcil
comparar la diferencia de la eficiencia del double stack en la red de prueba, mientras
el escenario de evaluacin siga evolucionando. Adems, existen otros factores que
intervienen en la valoracin realizada, como son el retardo o latencia de la red del
CINVESTAV, que le produce el usar como protocolo de enrutamiento interno a
RIPv1, as como afectan las condiciones atmosfricas a la operacin del enlace WAN
inalmbrico que conecta a nuestra institucin con Internet, y librar el firewall que
cuida la red.

Por otro lado, el modelo de base de datos back-ldbm que usa LDAP presenta
algunas desventajas en su operacin, como el realizar una sola operacin a la vez,
razn por la cual tiene que encolar las peticiones pendientes y su correspondiente
sobrecarga al servi dor donde corre el directorio. Por otro lado, la velocidad de los
procesadores de las computadoras usadas determina que tan rpido LDAP pueda
realizar las operaciones solicitadas.

6.1.1 Plataforma Solaris

En la figura 3 observamos que para la operacin de consulta al servidor LDAP, el

rendimiento mostrado usando direcciones globales IPv6 est muy por debajo (cerca
de 3.24% menos) de los mostrados por las direcciones IPv4 e IPv6 locales, esto es
porque al momento en que se utilizan direcciones IPv6 globales a travs de tneles es
necesario adicionar el encabezado de IPv4 al paquete de IPv6. Esto tiene dos efectos
negativos principales: primero, disminuye el tamao de la carga til de datos del
paquete IPv4; segundo, adiciona un factor adicional de retardo, ya que es necesario
desencapsular el paquete IPv4 a uno del tipo IPv6. Lo anterior incrementa la carga de
trabajo sobre procesador del servidor e incrementa la congestin sobre la red local.
 Cabe sealar, que cuando se manejan direcciones IPv6 locales el tratamiento de los
datagramas se hace de manera nativa.

Fig. 3. Rendimiento de LDAP al realizar consultas usando direcciones locales y globales IPv6
vs. Direcciones IPv4

La grfica 4 muestra que para la operacin de modificacin al servidor LDAP el

rendimiento mostrado usando direcciones globales IPv6 esta muy cercano a los
mostrados por IPv4 e IPv6 usando direcciones locales, esto es debido a que cuando se
realizan operaciones de modificacin al directorio, ste debe correr mecanismos de
control para mantener la consistencia de los datos contenidos en l, debido a las
limitaciones del modelo bacl-ldbm ya que este no opera en forma concurrente, lo cual
agrega un factor de retardo, mismo que se ve reflejado de mayor forma en
rendimiento mostrado con direcciones IPv4 y direcciones IPv6 locales. Importante
sealar que el double stack 6to4 de Solares es ms eficiente que el de Windows XP, el
cual presenta limitaciones.

6.1.2 Plataforma Windows

La grfica 5 muestra que no hay una diferencia tan pronunciada en cuanto a

rendimientos para la operacin de consulta como en el caso de Solaris, debido a la
manera en que Windows XP y Solaris implementan sockets. Sin embargo, es
necesario realizar mediciones ms detalladas para confirmar lo anterior.
Fig. 4. Rendimiento de LDAP al realizar consultas usando direcciones locales y globales IPv6
vs. Direcciones direcciones IPv4

Fig. 5. Rendimiento de LDAP al realizar modificaciones utilizando direcciones locales y

globales IPv6 vs. Direcciones IPv4
Fig. 6. Rendimiento de LDAP al realizar consultas utilizando direcciones locales y globales
IPv6 vs. Direcciones IPv4

La grfica 6 muestra al igual que la grfica 4 que para la operacin de

modificacin al servidor LDAP el rendimiento mostrado usando direcciones globales
IPv6 est muy cercano a los mostrados por IPv4 e IPv6 usando direcciones locales,
debido principalmente a que el modelo de base de datos bacl-ldbm tiene la limitante
de procesar un registro a la vez, lo cual confirma que cuando se realizan operaciones
de modificacin al directorio, el retardo adicional repercute de mayor manera en el
rendimiento mostrado con direcciones IP4 y direcciones IPv6 locales.

7 Conclusiones

En lo que respecta al rendimiento del servidor LDAP, se observa que en las

pruebas realizadas, en lo general ste tiene un mejor desempeo utilizando el
protocolo IPv4 e IPv6 con direcciones IPv6 locales que IPv6 con direcciones
globales. A grandes rasgos se puede explicar por dos razones fundamentales: la
primera, es que el encabezado de los paquetes IPv6 ocupa mayor espacio que la de los
paquetes de IPv4, haciendo que, con un tamao de paquete restringido a un tamao de
MTU dado, los paquetes IPv6 podrn transportar una carga til de datos menor a la de
los paquetes de IPv4 y esta definicin establece ya una limitante. La segunda es que el
protocolo IPv6 hace uso de la infraestructura de red IPv4 para el transporte de
paquetes (para direcciones IPv6 globales, ya que para direcciones IPv6 locales el
tratamiento de los paquetes es IPv6 nativo), lo que implica encapsular el paquete IPv6
dentro de una trama IPv4 para su transporte, y despus desencapsularlo al llegar a su
destino, agregando un retardo el cual tambin afecta al rendimiento del servidor.
Adems, dado que fue necesario utilizar el tnnel broker de Freenet6 como un
intermediario para obtener direcciones IPv6 globales, esto aumento la distancia en 3
saltos entre el cliente y el servidor.

7 Conclusiones

En lo que respecta al rendimiento del servidor LDAP, se observa que en las

pruebas realizadas, en lo general ste tiene un mejor desempeo utilizando el
protocolo IPv4 e IPv6 con direcciones IPv6 locales que IPv6 con direcciones
globales. A grandes rasgos se puede explicar por dos razones fundamentales: la
primera, es que el encabezado de los paquetes IPv6 ocupa mayor espacio que la de los
paquetes de IPv4, haciendo que, con un tamao de paquete restringido a un tamao de
MTU dado, los paquetes IPv6 podrn transportar una carga til de datos menor a la de
los paquetes de IPv4 y esta definicin establece ya una limitante. La segunda es que el
protocolo IPv6 hace uso de la infraestructura de red IPv4 para el transporte de
paquetes (para direcciones IPv6 globales, ya que para direcciones IPv6 locales el
tratamiento de los paquetes es IPv6 nativo), lo que implica encapsular el paquete IPv6
dentro de una trama IPv4 para su transporte, y despus desencapsularlo al llegar a su
destino, agregando un retardo el cual tambin afecta al rendimiento del servidor.
Adems, dado que fue necesario utilizar el tnnel broker de Freenet6 como un
intermediario para obtener direcciones IPv6 globales, esto aumento la distancia en 3
saltos entre el cliente y el servidor.

Agradecimientos

Los autores agradecemos expresamente el apoyo recibido de parte del Consejo de

Ciencia y Tecnologa (CONACyT) de Mxico bajo el proyecto 34528-A.
Agradecemos tambin las facilidades otorgadas por las compaas Sun Microsystems
de Mxico y Tecno S.A., en cuanto a recursos de cmputo.

Referencias.

1. Comer, Douglas E., Internetworking with TCP/IP Principles, Protocols, and Architectures,
vol. 1, 4th ed., 2000, Prentice Hall.
2. Howes, T. A., The Lightweight Directory Access Protocol: X.500 Lite, CITI Technical
Report 95-8, July 27 1995, Center for Information Technology Integration, University of
Michigan. http://www.citi.umich.edu/techreports/reports/citi-tr-95-8.pdf
3. IPv6: Deployment Strategies, December 23 2002, Cisco Systems.
http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/ipv6_sol/
4. IPv6 and the Future of the Internet, whitepaper, 1999, SunMicrosystems.
http://www.sun.com/software/whitepapers/wp-ipv6/ipv6wp.pdf
5. Raicu, I., Zeadally, S., Evaluating IPv6 on Windows and Solaris, IEEE Internet Computing,
May-Jun 2003.
6. Hagen, S., IPv6 Essentials, 2002, OReilly.
7. IPv6/Ipv4 Coexistence and Migration, August 2002, Microsoft Corporation.
http://www.microsoft.com/windowsserver2003/technologies/ipv6/ipv6coexist.mspx
8. Huitema, C., Routing In The Internet, 1995, Prentice Hall.
9. Morton, D., Understanding IPv6, PC Network Advisor, Issue 83, May 1997.
http://www.pcsupportadvissor.com/c0655.htm
10. Wang, X., Schulzrinne, H., Kandlur, D., and Verma, D.: Measurement and Analysis of
LDAP Performance. ACM SIGMETRICS Conference (2000) 156-165.
11 . Castro, E. M., de Miguel, Toms P., Programming guidelines on transistion to IPv6,
January 2003, Rey Juan Carlos University.
12. Application Performance Analysis In Transition Mechanism From Ipv4 to IPv6,
Proceedings APAN Conf. 2000, Tsukuba, Japan, Feb. 14-18, 2000.
http://www.my.apan.net/ipv6/
13. Phuket, Transition Mechanism Between IPv4 & IPv6 and deciding your choice, APAN
Conf. 2002, Jan. 22-25, Paper. http://www.my.apan.net/ipv6/
14. IPv6 Dual Stack Transition Technique Performance Analysis : KAME on FreeBSD as the
Case. Proceedings MMU International Symposium on Information and Communication
Technologies, Malaysia, 5th - 6th Oct., 2000. http://www.my.apan.net/ipv6/