TRABAJO MONOGRAFICO

ASIGNATURA: REDES Y BASE DE DATOS

TEMA: “DIRECCIONAMIENTO IPV6”

“BASE DE DATOS”

PRESENTADO POR:

ALUMNO: GUTIERREZ SOTO, LUIS EDUARDO

LIMA – PERÚ

2013

INDICE GENERALCAPITULO 1. DIRECCION IPV6............................................................................................4

1.1. DEFINICION...............................................................................................................4

1.2. TIPOS..........................................................................................................................4

1.3. FORMATOS DE DIRECCION.................................................................................5

a. Formato de dirección Unicast y Anycast...........................................................5

b. Formato de dirección de enlace-local................................................................6

c. Formato de dirección multicast Solicited-node...............................................6

d...........................................................................................................................................6

d. Formato de dirección Multicast...........................................................................6

e. Flags de la dirección Multicast............................................................................6

f. Formato de dirección multicast Prefijo-Unicast (unicast-prefix-based)....7

1.4. REPRESENTACION.................................................................................................7

1.5. REDES........................................................................................................................8

1.6. AMBITO DE DIRECCION IPV6...............................................................................9

1.7. ESPACIO DE DIRECCIONAMIENTO IPV6........................................................10

a. Asignación general..................................................................................................10

b. Direcciones anycast reservadas............................................................................11

1.8. SELECCIÓN AUTOMATICA DE DIRECCION...................................................12

1.9. TRANSICION...........................................................................................................13

CAPITULO 2. SERVIDORES DE BASE DE DATOS........................................................14

a. Servidores de bases de dato relacionales..........................................................15

2.1. LA SEGURIDAD......................................................................................................17

2.2. EL SOPORTE DE RED..........................................................................................18

2.3. INTERNET Y BASES DE DATOS DISTRIBUIDAS...........................................19

2.4. HERRAMIENTAS DE ADMINISTRACIÓN..........................................................21

2.5. PLATAFORMAS Y PROGRAMACIÓN...............................................................24

2.6. EL SOPORTE HARDWARE NECESARIO.........................................................25

3. CONCLUSIONES............................................................................................................26

a. Ipv6................................................................................................................................26

b. Base de Datos............................................................................................................26

4. RECOMENDACIONES...................................................................................................26

a. Ipv6................................................................................................................................26

b. Base de Datos............................................................................................................27

5. BIBLIOGRAFIA...............................................................................................................27

a. Ipv6................................................................................................................................27

b. Base de Datos............................................................................................................27

CAPITULO 1. DIRECCION IPV6

1.1. DEFINICION

Una Dirección de Internet Protocol Versión 6 (Dirección IPv6) es

una etiqueta numérica usada para identificar un interfaz de

red (elemento de comunicación/conexión) de un ordenador o nodo de

red participando en una red IPv6.

Las direcciones IP se usan para identificar de manera única una

interfaz de red de un Host, localizarlo en la red y de ese modo

encaminar paquetes IP entre hosts. Con este objetivo, las direcciones

IP aparecen en campos de la cabecera IP indicando el origen y destino

del paquete.

IPv6 es el sucesor del primer protocolo de direccionamiento

de Internet, Internet Protocol versión 4 (IPv4). A diferencia de IPv4, que

utiliza una dirección IP de 32 bits, las direcciones IPv6 tienen un

tamaño de 128 bits. Por lo tanto, IPv6 tiene un espacio de direcciones

mucho más amplio que IPv4.

1.2. TIPOS

Las direcciones IPv6 se clasifican según las políticas de

direccionamiento y encaminamiento más comunes en redes:

direcciones unicast, anycast y multicast.1

Una dirección unicast identifica un único interface de red. El

protocolo de Internet entrega los paquetes enviados a una

dirección unicast al interface específico.

Una dirección anycast es asignada a un grupo de interfaces,

normalmente de nodos diferentes. Un paquete enviado a una

dirección anycast se entrega únicamente a uno de los miembros,

típicamente el host con menos coste, según la definición de

métrica del protocolo de encaminamiento. Las direcciones anycast

no se identifican fácilmente pues tienen el mismo formato que las

unicast, diferenciándose únicamente por estar presente en varios

puntos de la red. Casi cualquier dirección unicast puede utilizarse

como dirección anycast.

Una dirección multicast también es usada por múltiples hosts, que

consiguen la dirección multicast participando en el protocolo de

multidifusión (multicast) entre los routers de red. Un paquete

enviado a una dirección multicast es entregado a todos los

interfaces que se hayan unido al grupo multicast correspondiente.

IPv6 no implementa direcciones broadcast. El mismo efecto puede

lograrse enviando un paquete al grupo de multicast de enlace-local

todos los nodos (all-nodes) ff02::1. Sin embargo, no se recomienda el

uso del grupo all-nodes, y la mayoría de protocolos IPv6 usan un grupo

multicast de enlace-local exclusivo en lugar de molestar a todos los

interfaces de la red.

1.3. FORMATOS DE DIRECCION

Una dirección IPv6 está formada por 128 bits.1 Las direcciones se

clasifican en diferentes tipos: unicast, multicast y anycast. Cada uno de

los tipos define valores específicos para subgrupos de los 128 bits,

asociando dicho valor con las características especiales del tipo.

a. Formato de dirección Unicast y Anycast

Las direcciones Unicast y anycast generalmente se dividen en dos

grupos lógicos: los primeros 64bits identifican el prefijo de red, y

son usados para encaminamiento; los últimos 64bits identifican el

interface de red del host.

Ejemplo de formato de dirección unicast (el tamaño del routing-prefix es

variable)

bits 48 (o más) 16 (o menos) 64

campo routing prefix subnet id interface identifier

El prefijo de red (network prefix) (prefijo de encaminamiento

o (routing prefix) junto con el identificador de subred o (subnet id))

está situado en los 64 bits más significativos de la dirección ipv6. El

tamaño del routing prefix puede variar; un prefijo de mayor tamaño

significa un tamaño menor para subnet id. El subnet id permite a

los administradores de red definir subredes dentro de la red

disponible.

Los 64 bits de identificador del interface (interface identifier) son

generados automáticamente con la dirección MAC del interface y el

algoritmo EUI-64 modificado, obtenidos de un servidorDHCPv6,

establecidos aleatoriamente o asignados manualmente.

Una dirección de enlace-local es una dirección unicast, pero

usando un valor específico para el network prefix.

b. Formato de dirección de enlace-local

El campo prefijo contiene el valor binario 1111111010 (fe80::/10).

Los 54 ceros siguientes consiguen que el prefijo de red sea el

mismo para todas las direcciones locales, y por tanto no enrutable.

c. Formato de dirección multicast Solicited-node

d.

d. Formato de dirección Multicast

Las direcciones Multicast se construyen en función de

determinadas reglas, dependiendo de la aplicación.

bits 8 4 4 112

campo prefix flagsscop

egroup ID

valor1111111

10RPT XXXX

El campo prefix mantiene el valor binario 11111111 para cualquier

dirección multicast.

Actualmente se utilizan 3 de los 4 bits del campo flags (flags);1 el bit

de flag más significativo está reservado para uso futuro.

e. Flags de la dirección Multicast

bits 10 54 64

campo prefijo ceros interface identifier

bits 8 4 4 79 9 24

camp

oprefix flags scope ceros unos dirección unicast

valor 11111111 0000 0010 00000000...00000000 111111111

Flag 0 1

R

(Rendezvous)

Rendezvous point not embedded

(traducción necesaria)

Rendezvous point embedded

(traducción necesaria)

P (Prefijo) Sin información de prefijo Dirección basada en prefijo de red

T (Transitoria)Dirección multicast mundialmente

válida (permanente)

Dirección multicast asignada

dinámicamente (temporal)

Los 4-bits del campo scope (ámbito) se utilizan para indicar dónde

la dirección es válida y única.

Hay direcciones multicast especiales, como la Solicited-node:

Los campos prefix y scope tienen los valores

binarios 11111111 y 0010. Las direcciones multicast Solicited-

node son construidas a partir de la dirección unicast o anycast,

copiando los últimos 24 bits de la dirección unicast o anycast en los

últimos 24 bits de la dirección multicast.

f. Formato de dirección multicast Prefijo-Unicast (unicast-prefix-

based)

bits 8 4 4 4 4 8 64 32

camp

oprefix

flg

ssc res

rii

dplen prefijo de red group ID

Las direcciones multicast de multidifusión (link-scoped) usan un

formato parecido.

1.4. REPRESENTACION

Una dirección IPv6 (128 bits) se representa mediante ocho grupos de

cuatro dígitos hexadecimales, cada grupo representando

16 bits (dos octetos). Los grupos se separan mediante dos puntos(:).

Un ejemplo de dirección IPv6 podría ser:

2001:0db8:85a3:0000:0000:8a2e:0370:7334

Los dígitos hexadecimales no son sensibles a mayúsculas/minúsculas,

pero se aconseja la utilización de minúsculas.9

Esta representación completa puede ser simplificada de varias

maneras, eliminando partes de la representación.

a. Ceros iniciales

Los ceros iniciales de cada grupo pueden omitirse, aunque cada

grupo debe contener al menos un dígito hexadecimal.1 De ese

modo, la dirección IPv6 ejemplo podría escribirse:

2001:db8:85a3:0:0:8a2e:370:7334

b. Grupos de ceros

Uno o más grupos de ceros pueden ser sustituidos por dos

puntos.1 Esta sustitución puede realizarse únicamente una vez en

la dirección. En caso contrario, obtendríamos una representación

ambigua. Si pueden hacerse varias sustituciones, debemos hacer

la de mayor número de grupos; si el número de grupos es igual,

debemos hacer la situada más a la izquierda.9 Con esta regla,

reduciríamos aún más la dirección ejemplo:

2001:db8:85a3:8a2e:370:7334

La dirección de loopback, 0:0:0:0:0:0:0:1, y la dirección IPv6

indefinida, 0:0:0:0:0:0:0:0, se reducen a ::1 y :: respectivamente.

c. Notación decimal con puntos

Durante la transición de Internet de IPv4 a IPv6 será típico operar

en entornos de doble direccionamiento (IPv4 e IPv6). Por este

motivo se ha introducido una notación especial para expresar

direcciones IPv6 que sean IPv4-mapeada o IPv4-compatible,

representando los últimos 32 bits de la dirección IPv6 en el formato

decimal con puntos usado en IPv4.

Por ejemplo, la dirección IPv6 del tipo IPv4-

mapeada ::ffff:c000:280 se puede representar

como ::ffff:192.0.2.128, mostrando claramente la dirección IPv4

mapeada dentro de la IPv6.

1.5. REDES

Una red IPv6 utiliza un grupo de direcciones IPv6 contiguas, de un

tamaño potencia de dos. La parte inicial de las direcciones son

idénticas para todos los hosts de una red, y se llama dirección de red o

prefijo de encaminamiento (routing prefix). Las direcciones de red se

escriben en notación CIDR una red se representa por la primera

dirección del grupo (que debe terminar en ceros), una barra

invertida (/), y el número de bits del prefijo en decimal. Por ejemplo, la

red 2001:db8:1234::/48 comienza en la

dirección 2001:0db8:1234:0000:0000:0000:0000:0000 y finaliza

en 2001:0db8:1234:ffff:ffff:ffff:ffff:ffff.

Veámoslo con mayor detalle:

1.6. AMBITO DE DIRECCION IPV6

Toda dirección IPv6, excepto la dirección indefinida (::), tiene un

"ámbito" (scope en inglés),11 que determina en qué partes de la red es

válida.

En direccionamiento unicast, las direcciones de enlace-local y

la dirección de loopback tienen ámbito de enlace local, es decir, deben

ser usadas en la red directamente conectada. El resto de direcciones,

excepto aquellas privadas, tienen ámbito global (o universal), que

significa que son mundialmente enrutables y pueden ser usadas para

conectarse a direcciones de ámbito global en cualquier lugar, o a

direcciones de ámbito enlace-local en la red directamente conectada.

El ámbito de una dirección anycast se define del mismo modo que en

las direcciones unicast.

Para multicast, los cuatros bits menos significativos del segundo octeto

de una dirección multicast (ff0X::) identifican el ámbito, es decir, hasta

dónde se propaga el tráfico multicast. Los ámbitos1 definidos

actualmente son:

Ámbito dirección IPv6 Multicast

Valor Ámbito Descripción

(scope)

0x0 reserved

0x1 interface-localEl ámbito interface-local abarca sólo un único interfaz de un nodo,

y es útil sólo para la transmisión loopback del tráfico multicast.

0x2 link-localLos ámbitos de enlace-local y site-local abarcan las mismas

regiones que los ámbitos unicast correspondientes.

0x4 admin-local

El ámbito admin-local es el más pequeño que debe ser

configurado manualmente, es decir, no deriva automáticamente de

la conexión física sin relación alguna con multicast.

0x5 site-localLos ámbitos de enlace-local y site-local abarcan las mismas

regiones que los ámbitos unicast correspondientes.

0x8organization-

local

El ámbito de organization-local abarca multiples ubicaciones que

pertenecen a la misma organización.

0xe global

0xf reserved

1.7. ESPACIO DE DIRECCIONAMIENTO IPV6

a. Asignación general

El Internet Architecture Board (Comité de Arquitectura de

Internet) y el Internet Engineering Steering Group (Dirección de

Ingeniería de Internet) delegaron la asignación del

direccionamiento IPv6 en la Internet Assigned Numbers

Authority (IANA).12 Su función principal es la asignación de

grandes bloques de direcciones a los Registros Regionales de

Internet (RIRs por sus siglas en inglés), que tienen la tarea de

asignar trozos menores a Proveedores de Internet u otros registros

locales. IANA ha mantenido la lista oficial de las asignaciones del

espacio de direcciones IPv6 desde diciembre de 1995.13

Actualmente, sólo la octava parte del espacio total de direcciones

están disponibles para su uso en Internet. La mayor parte de las

direcciones IPv6 están reservadas para uso futuro. Para conseguir

agregación de rutas, reduciendo así el tamaño de las tablas de

rutas de Internet, el rango 2000::/3 se asigna a los RIRs en grandes

bloques desde /23 hasta /12.14

Los RIRs asignan rangos menores a ISPs, que luego distribuyen en

bloques de /48 a sus clientes. Los registros de asignaciones

globales pueden encontrarse en los RIRs u otros webs.15

Las direcciones IPv6 se asignan a las organizaciones en bloques

mucho mayores a las asignaciones IPv4; la asignación

recomendada es un rango /48, que es 248 ó 2.8×1014 veces mayor

que el direccionamiento IPv4 completo. A pesar de ello, el conjunto

total es suficiente para el futuro previsible, pues hay 2128 ó sobre

3.4×1038 direcciones IPv6.

Cada RIR puede dividir cada uno de sus bloques /23 en 512

bloques /32, normalmente uno para cada ISP. Un ISP puede dividir

cada uno de sus rangos /32 en 65.536 bloques /48, normalmente

uno para cada cliente.16 Los clientes pueden crear 65.536

redes /64 con su asignación /48, teniendo cada red un número de

direcciones que es el cuadrado de todo el espacio de direcciones

IPv4, que sólo tenía 232 ó 4.3×109 direcciones.

Tal y como se ha diseñado, sólo una pequeña fracción del espacio

de direcciones se utilizarán realmente. El amplio espacio de

direcciones asegura que prácticamente siempre habrá

disponibilidad, lo que convertirá a la traducción de

direcciones (NAT) en innecesaria desde un punto de vista de

direccionamiento. NAT se utiliza actualmente sobre todo para

aliviar elagotamiento de las direcciones IPv4, pero también tiene

aspecto económico ya que el alquiler de direcciones IP tiene un

coste. Desde un punto de vista de la seguridad evita exponer

información de estructura y gestión interna de red hacia internet.

b. Direcciones anycast reservadas

La dirección más baja de cada subred (identificador de interface

todo a ceros) está reservada como dirección anycast subnet-

router (subred de router).1 Las aplicaciones pueden utilizar esta

dirección destino para hablar con algún router de la subred,

garantizando IPv6 que estos paquetes son entregados únicamente

a un router de la subred.

Las 128 direcciones más altas de cada subred /64 están

reservadas como direcciones anycast.17 Estas direcciones suelen

tener los 57 primeros bits del identificador de interface a 1,

seguidos de 7 bits de identificador anycast. Los prefijos de red,

incluidos subredes, requieren tener 64 bits de longitud, en cuyo

caso el bit universal/local debe ser puesto a 0 para indicar que la

dirección no es globalmente única. Si la dirección tiene el

valor 0x7e en los 7 bits menos significativos, se define como una

dirección anycast de home agent (agente inicial) en IP Móvil. La

dirección con los 7 bits menos significativos a 1 (valor 0x7f) está

reservada y no puede ser usada. No hay más asignaciones, por lo

que los valores desde 0x00 hasta 0x7d están reservados también.

1.8. SELECCIÓN AUTOMATICA DE DIRECCION

Los interfaces de red habilitados para IPv6 tienen normalmente más de

una dirección IPv6, por ejemplo una dirección de enlace-local y una

dirección global, o direcciones permanentes versus temporales. IPv6

introduce los conceptos de alcance y preferencia, dando múltiples

opciones para seleccionar la dirección origen y destino en

comunicaciones con otros hosts.

El algoritmo de selección de preferencia,33 que elige la dirección más

apropiada para usar en la comunicación con un destino concreto

(incluyendo el uso de direcciones IPv4-mapeadas en implementaciones

de doble pila) está basado en una tabla de preferencias configuradas

por el usuario, que asocia cada prefijo de red con un nivel de prioridad.

La tabla por defecto sería como la siguiente:

Tabla de Políticas de Prefijos

Prefijo Prioridad Etiqueta

::1/128

::/0

2002::/16

::/96

50

40

30

20

0

1

2

3

::ffff:0:0/96 10 4

En una configuración por defecto, IPv6 tendrá mayor prioridad que

IPv4, y también utilizará direcciones destino con el ámbito más

pequeño posible, de modo que las comunicaciones de enlace-local son

preferidas a caminos globales cuando ambos sean igualmente

adecuados. La tabla de políticas de prefijos es similar a una tabla de

rutas, con el valor de prioridad haciendo de coste de enlace y donde

mayor preferencia es expresada como un valor mayor. Las direcciones

origen candidatas se obtienen del Sistema Operativo, y las direcciones

destino candidatas pueden ser consultadas vía Domain Name

System (DNS). Después se cruzan con la tabla de políticas de prefijos,

seleccionando el prefijo de mayor número de bits de entre las entradas

donde la dirección IPv6 hace match.

1.9. TRANSICION

Desde 2009, muchos dispositivos NAT y routers en los hogares todavía

gestionan incorrectamente los registros AAAA.35 Algunos de ellos

simplemente desechan las peticiones DNS a estos registros, en lugar

de devolver una respuesta negativa apropiada. Debido a que la petición

es desechada, el host debe esperar el timeout de esa petición. Esto, a

menudo, causa una percepción de lentitud en la conexión de hosts

IPv6.

CAPITULO 2. SERVIDORES DE BASE DE DATOS

Grandes proveedores de información para todo tipo de usuarios.

Los servidores de bases de datos surgen con motivo de la necesidad de las

empresas de manejar grandes y complejos volúmenes de datos, al tiempo

que requieren compartir la información con un conjunto de clientes (que

pueden ser tanto aplicaciones como usuarios) de una manera segura. Ante

este enfoque, un sistema gestor de bases de datos (SGBD, a partir de

ahora) deberá ofrecer soluciones de forma fiable, rentable y de alto

rendimiento. A estas tres características, le debemos añadir una más: debe

proporcionar servicios de forma global y, en la medida de lo posible,

independientemente de la plataforma. Internet se ha convertido en nuestros

días en la mayor plataforma de comunicaciones jamás vista. Esto hace que

las empresas tiendan a presentar su información a través de la Web en

forma de contenidos, que después los clientes consultarán para establecer

relaciones con dichas empresas.

Una de las funciones que se empieza a exigir a los SGBD, puesto que

sobre ellos recae el peso del almacén y proceso de la información, es la de

proporcionar herramientas de apoyo a toma de decisiones

("datawarehouse") al tiempo que proporciona una plataforma de

transacciones "on-line" (OLTP) que hacen que la información esté siempre

actualizada y consistente. A lo largo del artículo iremos comentando las

prestaciones de ambas implementaciones y cómo influye el SGBD en el

proceso de las mismas.

Aunque parece clara la función de un SGBD, en la actualidad cada vez

más filosofías y tecnologías tienden a confluir en un mismo punto. Ya se

está hablando acerca de las posibilidades de los nuevos SGBD de poder

almacenar contenidos multimedia, objetos, documentos complejos... La

explosión de nuevos servicios ha hecho que cada vez más aplicaciones

dependan de estos servidores de datos, delegando la responsabilidad de la

gestión y almacenamiento de la información a aquellos que mejor están

preparados para su tratamiento.

Para poder lograr estos objetivos, es un punto muy importante el que los

SGBD proporcionen herramientas de administración completas (que

simplifiquen la tarea de la configuración, seguridad, creación y gestión de

bases de datos al tiempo que proporcionan mecanismos de integración con

otros sistemas y políticas de copias de seguridad) y herramientas que

permitan su programación (tanto a nivel de diseño como a nivel de reglas y

procedimientos que encapsulen la arquitectura de la base de datos, de tal

manera que, a través de conectores a datos, las aplicaciones sólo tengan

que pedir la información que necesitan sin preocuparse de cómo se

encuentra almacenada).

Por último, puesto que los datos deben estar por encima de la plataforma,

los SGBD deben proporcionar mecanismos de comunicación con otras

plataformas que actúen también como clientes o servidores de datos. Lo

que nos lleva al último punto que consideraremos: la posibilidad de la

replicación de la información, posibilidad que permitirá que la información

pueda estar almacenada en múltiples servidores de datos y accesible

desde cualquier punto como si se tratase de un único volumen de

información.

a. Servidores de bases de dato relacionales

Antes de comenzar a comentar las características a analizar de los

SGBD, el primer paso es el de definir qué es un servidor de bases de

datos relacionales y sus cometidos principales. Un servidor de bases

de datos relacionales es un sistema bajo arquitectura cliente/servidor

que proporciona servicios de gestión, administración y protección de la

información (datos) a través de conexiones de red, gobernadas por

unos protocolos definidos y a los que acceden los usuarios, de modo

concurrente, a través de aplicaciones clientes (bien sean herramientas

del propio sistema como aplicaciones de terceros).

Dichos servidores solucionan los problemas de las empresas al

manejar grandes volúmenes de información de una manera estable,

fiable, coherente y segura en un entorno heterogéneo de trabajo y de

necesidades de información.

La información se almacenará de modo lógico de una manera

relacional, como ya se ha visto, en la que un conjunto de

almacenamientos que llamaremos tablas (y que se componen de un

conjunto de campos que describen su contenido, y a los cuales

denominaremos columnas) se relacionan entre sí a través de un

conjunto definido de claves. Una de las responsabilidades del sistema y

del diseño de la base de datos, será el que sea posible mostrar aquella

información requerida a través de conjuntos de datos planos (que

llamaremos cursores), independizando las relaciones establecidas y la

arquitectura de la base de datos de la necesidad de información del

usuario. Para proteger la información el sistema contará con

mecanismos de control de transacciones basados en reglas que

denominaremos disparadores, reglas de definición del tipo de entrada

de datos y reglas de validación de las entradas de datos. Mediante

complejos sistemas de indexación, estos sistemas serán capaces de

ordenar y acelerar las consultas a la información requerida. Cuanto

mejor se indexen los datos, más rápidas se realizarán las consultas.

Por último, y como un factor muy importante de cara al diseño de bases

de datos, los sistemas deben proporcionar la posibilidad de automatizar

operaciones de acceso, filtrado y control de los datos, a través de los

procedimientos almacenados.

Todo ello se podrá realizar a través del lenguaje SQL (Structured Query

Language, lenguaje estructurado de consulta) que se ha convertido en

el estándar de interfaz de estos sistemas para su diseño, desarrollo y

consultas de informaci6n. Desarrollado por IBM, se ha convertido en un

estándar para el manejo de estos sistemas y queda recogido en la

norma ANSI SQL'92, en la cual quedan registradas aquellas sentencias

SQL que deben estar presentes en todo sistema gestor de bases de

datos. En este apartado, que es donde los SGBD demuestran sus

propios dones, es donde ya nos separamos del estándar, pues cada

fabricante añadirá sus propias extensiones al lenguaje para

aprovechar, como es lógico, las ventajas de sus propios motores.

De lo indicado en los párrafos anteriores podremos obtener algunos de

los parámetros que emplearemos en la comparativa: capacidad del

servidor de conexión con el exterior; capacidad de atender peticiones

concurrentes de clientes; seguridad del sistema; herramientas de

administraci6n disponibles; herramientas de administración y

automatización de tareas que reduzcan el TCO ("Total Cost Owner") y,

por último, la cantidad de plataformas en la que se puede integrar el

sistema.

2.1. LA SEGURIDAD

En todo sistema abierto, debe proporcionarse un potente mecanismo

de seguridad que garantice que ningún intruso pueda acceder o

corromper la integridad del sistema. Si este concepto ya es crítico en

los sistemas operativos actuales, hay que imaginarse cuánto más es

de importante este concepto cuando ya no hablamos de recursos del

sistema (como puedan ser archivos o correos, más o menos

importantes) sino de información crítica para la empresa, en la que se

almacenan datos de contabilidad, gestión, personal, o estratégicos de

la cual depende para su existencia.

En servidores de bases de datos hablaremos de la seguridad a 4

niveles básicos: seguridad de acceso al sistema, seguridad a nivel de

objetos de datos, seguridad a nivel de datos y seguridad en cuanto a

protección de los almacenamientos físicos de los datos.

La seguridad de acceso se implementará de dos maneras posibles: a

nivel de sistema operativo, en cuyo caso el SGBD se apoya en la

seguridad de entrada al sistema operativo para comprobar la validez

del acceso a los datos almacenados; o bien lo que llamaremos modo

mixto, en el cual la seguridad de entrada a la información la llevará a

cabo el propio servidor de datos a partir de la definición de cuentas de

usuario al servidor (su denominación de mixta proviene de la

capacidad de los sistemas de incluir como cuentas de acceso o login

aquellas propias del sistema operativo, lo que facilita la transición de

las cuentas de seguridad). La segunda será de gran ayuda cuando los

clientes que acceden al sistema provienen de sistemas operativos con

poca (o ninguna) seguridad o de aplicaciones instaladas que

necesiten acceder a los volúmenes de información del sistema. En

ambos casos, en los sistemas se contará con roles o papeles con los

que contará el usuario al entrar al sistema para la realización de

determinadas operaciones de cara al sistema.

La seguridad a nivel de objetos entra ya en el detalle del acceso a

nivel de creación y administración de objetos de datos: tablas, vistas,

índices, relaciones, reglas...etc. Es decir, las responsabilidades y

acciones que puede hacer el usuario en el esquema de la base de

datos (el esqueleto a partir del cual el sistema definirá cómo se debe

almacenar y relacionar la información). Se podrán especificar de

nuevo roles a los usuarios, indicando quién podrá crear, modificar o

eliminar cualquier objeto de datos (con lo que se permite establecer

una política de delegación de responsabilidades).

La seguridad a nivel de datos entra ya en la capa de la información en

sí. En la que indicaremos quién puede acceder a qué información

para su consulta, actualización, inserción o borrado. Las

características de los diversos motores determinarán hasta qué grado

de seguridad se llega en este apartado (desde la protección de las

columnas de una tabla hasta la tabla en sí, creación de vistas...etc.).

Por último, la seguridad a nivel de protección de los almacenamientos

físicos de la información. Tendremos dos aproximaciones: la

seguridad a nivel de sistema operativo de los archivos de datos del

sistema, y las políticas de copia de seguridad y restauración de los

datos (tanto con herramientas del sistema operativo como las

proporcionadas por el propio servidor de datos) junto con sus posibles

aproximaciones (total, incremental y diferencial), además de los

soportes hardware compatibles de almacenamiento masivo

empleados como destino de las copias.

2.2. EL SOPORTE DE RED

Puesto que se está implementando una solución cliente/servidor, es

un elemento fundamental para la conexión entre los distintos clientes

y el servidor un canal apropiado para la comunicación, que posibilite

el intercambio de información. Los servidores de datos deben

proporcionar mecanismos de comunicación óptimos, pues de cómo se

envíe la información dependerán parámetros tan importantes como la

velocidad de acceso a los datos. Todos los sistemas gestores

analizados cuentan con múltiples configuraciones de protocolos,

adaptándose a los protocolos existentes y estandarizados de la

actualidad: TCP/IP, IPX, Banyan..., aunque el que tiene un auge

imparable en este tipo de servicios es el omnipresente TCP/IP, lo que

garantiza que la conexi6n de nuestros servidores estará al alcance de

cualquier usuario desde cualquier parte del mundo.

Es importante no sólo el canal de comunicaciones que está disponible

para los servidores de datos sino también cómo es transmitida la

información. Es lógico pensar que tienen que existir posibilidades de

encriptación de la información para prevenir accesos no autorizados

así como mecanismos de partición de los datos, para evitar que

peticiones masivas de información sobrecarguen el ancho de banda

de la red. Además, será una cuestión de optimización el saber que no

toda la información es necesaria al mismo tiempo, y que el servidor

debe ser capaz de ir proveyendo la información requerida en el

momento justo en el que es necesaria (lo que ahorra ancho de banda

y recursos de la máquina).

La configuración de las librerías de red dependerá mucho del tipo de

sistema operativo que se encuentre en explotación. Y será un

componente a configurar tanto en la máquina servidor como en los

puestos cliente.

Este apartado también dependerá del tipo de plataforma empleada.

Recalcar que el proceso de configuración de los clientes deberá ser

un proceso sencillo, que en la mayoría de los casos sólo implica

conocer el nombre del servidor de datos y las cuentas oportunas,

siendo el propio sistema operativo el encargado de encontrar los

servidores referenciados (bien a través de un nombre DNS, una

dirección IP o un nombre de servicio con un Puerto de escucha).

2.3. INTERNET Y BASES DE DATOS DISTRIBUIDAS

Puesto que todo tiende a unificarse con Internet, los servidores de

datos también deben proporcionar servicios de datos a la Red. Los

servicios disponibles incorporan generación y alimentación de páginas

Web a partir de consultas prediseñadas en la base de datos.

Dichas consultas mantendrán alimentadas las páginas Web, las

cuales estarán siempre actualizadas con la última información.

Cuanto mayor sea el grado de integración con la Web, mejor podrá

ser la presentación de información crítica de la empresa en las

páginas. Los servidores de datos deben proporcionar mecanismos de

actualización automática de las páginas, de manera que se asegure

que cualquier cambio efectuado en la base de datos se haga efectivo

en la correspondiente página Web. De esta manera, la integridad de

la informaci6n también estará implementada a nivel de servicios de la

Red. Lógicamente, también hay que pensar que esto no es viable de

cara a actualizaciones masivas de datos, lo que implica una

sobrecarga del servidor (pues no sólo actualiza datos sino también

páginas Web). Por ello, generalmente deberemos contar con

opciones que permitan realizar actualizaciones manuales o

programadas en el tiempo (lo que reducirá significativamente el coste

de actualización de las páginas).

No sólo es importante el nivel de integración con el Web, sino que

también es importante el grado de interacción del usuario con la

misma. Generalmente las páginas Web proporcionan mecanismos de

selección de información personalizada, lo cual permite que los

usuarios accedan sólo a aquella información que precisan. Para ello,

es importante que exista un soporte de interacción que se obtiene a

través de código Java. Por lo tanto, cuanto mejor sea el soporte Java,

más se asegura la interacción y se amplía el rango de servicios que

puede proporcionar el servidor de datos.

Una de las mejoras realizadas como consecuencia de la integración

con la Red Global, es la de la posibilidad de permitir la compartición y

distribución de la información a lo largo de los servidores situados en

cualquier parte del mundo. Esto permitirá a las empresas disponer de

su información sea cuál sea el lugar del mundo en el que se

encuentre el departamento que la procesa. E, incluso, permitirá a las

empresas poder integrar sus bases de datos con sus proveedores o

clientes, de manera que podrán colaborar a nivel de servicios y

recursos de información, ganando en rapidez y fiabilidad. Para ello,

los servidores de datos deberán proporcionar los servicios de

intercambio de información, reglas de sincronización y todo un

conjunto de parámetros necesarios para que esta revolución en

cuanto a acceso global a la información sea posible.

2.4. HERRAMIENTAS DE ADMINISTRACIÓN

Avanzando un grado más en las capas de servicios que debe

proporcionar un servidor de datos, nos encontramos con las

herramientas que proporciona tanto al usuario administrador como al

cliente consumidor de los datos. De cara al administrador, las

herramientas deben proporcionarle un entorno amigable y sencillo de

manejar, que le permita orientarse a su trabajo y no preocuparse con

detalles de más bajo nivel, al tiempo que le permite realizar sus tareas

de la manera más rápida y simplificada posible. Indicar que cuanto

mayor sea el nivel de automatización de las tareas, menor será el

tiempo que tenga que dedicar a tareas generalmente repetitivas. Y

cuanto mayor sea el número de opciones configurables, mejor

servicio se podrá obtener de dichas tareas. La comodidad de acceso

a las herramientas es otro parámetro a tener en cuenta. Cuanta más

información tengamos a nuestro alcance, menor será el tiempo

empleado en acceder a la información necesaria para la

administración del servidor. No será extraño acceder a las opciones

de configuración y gestión a través de consolas que permitan la

integración de "snap-ins" o que, al menos, sirvan de pasarela entre las

múltiples utilidades disponibles. Dichas herramientas, además, deben

permitir la administración remota del servidor o servidores que estén a

cargo del administrador. De nuevo, insistir en el grado de

programación y automatización de tareas, ya que este mecanismo

proveerá de la creación de planes automáticos de realización de

tareas repetitivas de administración, lo que garantiza un alto grado de

seguridad, optimización, ahorro de tiempo y esfuerzo.

Como un componente fundamental de un servidor de datos, es el de

Optimización de la Base de datos y de las consultas. Cuanto más

efectiva sea la optimización del sistema, mayor velocidad adquirirán

las consultas y mejor rendimiento se obtendrá del servidor. Muchas

veces la velocidad no se encuentra en una máquina sobrada de

recursos, sino en aprovechar al máximo los recursos de los que

disponemos. Por lo tanto, cuanto mejor sea el soporte de optimización

para el administrador, mejor se podrá configurar el sistema, lo que

asegurará siempre un rendimiento máximo adaptado a las

necesidades de la empresa.

Las consultas y su proceso

El servicio más importante que proporciona un servidor de datos es el

del acceso a la información que almacena. El cómo recuperar y

actualizar dicha información es un proceso crítico del que depende en

mayor grado el éxito de este tipo de sistemas. El lenguaje que se

emplea en la actualidad es el SQL bajo el estándar ANSI SQL'92.

Esto, como comentamos anteriormente, garantiza que todo conjunto

de sentencias empleado para el acceso a una base de datos puede

ser empleado para cualquier tipo de servidor de bases de datos que

siga este estándar. Lo que independiza la necesidad de información

del cómo se encuentre almacenada.

Las herramientas actuales permiten encapsular el código SQL, de tal

manera que el usuario no tiene que conocer dicho lenguaje para

acceder a la información. Incluso, y gracias a los procedimientos

almacenados, es posible encapsular el código SQL dentro de la

propia base de datos, lo que da lugar a la petición de información

únicamente a través de un conjunto documentado de funciones

sencillas. Esto de cara a aplicaciones y usuarios simplifica el acceso a

la base de datos, y protege la arquitectura de la misma.

La optimización automática de consultas SQL es una nueva opción

que proporcionan los nuevos servidores de datos. Esto permite que

sea el propio servidor el que reconozca la mejor manera de recuperar

la información (optimización y asignación automática de índices, o

aprendizaje/ entrenamiento de consultas) que es lo que se conoce

como plan de ejecución de la consulta. Lo que en el caso de introducir

una sentencia SQL no optimizada por motivos de rapidez o

desconocimiento, permite acelerar al máximo el acceso a los datos.

Esto, junto con las capacidades multiproceso de los servidores,

permite que la ejecución de consultas complejas se convierta en una

operación rápida y de alto rendimiento.

Este apartado es muy importante de cara a la implementación de

aplicaciones OLTP (en las cuales es crítica la velocidad de

actualización de la información en línea) y en entornos

datawarehouse (en el que las consultas de recuperación de

información para la toma de decisiones dependen de consultas muy

complejas en proceso que devuelven valores calculados muy

concretos).

Por último, indicar en este apartado que será una opción de valor

añadido el incorporar servicios de datawarehouse, que permitan la

implementación de este tipo de arquitecturas en la empresa.

En el caso de aplicaciones OLTP.es muy importante el asunto de los

bloqueos de objetos de datos, pues el sistema gestor debe mantener

la integridad de la información que está siendo actualizada por

múltiples clientes al mismo tiempo. De no ser así, se podrían obtener

situaciones de registros fantasma, información de cálculo erróneo, e

información desactualizada. Habrá que estudiar cuál es el sistema

que ofrece un grado muy fino de bloqueo, pues cuanto menor sea el

nivel de bloqueo (se bloquea sólo lo justo) más usuarios podrán

acceder a los recursos al mismo tiempo. Un bloqueo a nivel de

columna permite a los usuarios acceder y modificar aquellas

columnas que no están siendo actualizadas por otros usuarios, dentro

de la misma fila. Un bloqueo a nivel de tabla paralizará temporalmente

las operaciones de aquellos usuarios que no tienen el acceso a dicho

recurso hasta que el operador termine su operación.

En este apartado, uno de los factores críticos es el del control de las

transacciones. Las transacciones son un conjunto de operaciones que

se realizan como una unidad de ejecución y que deben terminar con

éxito (en cuyo caso se actualiza la información implicada en todos los

pasos, se denomina "commit") o en fracaso (en cuyo caso el servidor

debe ser capaz de deshacer toda la operación para dejar la base de

datos en el último estado consistente, conocido como

"rollback"). Cuanto mayor sea el grado de recuperación y control de

las transacciones, mayor integridad se obtendrá en la base de datos.

Y este control se propaga en cuanto a transacciones distribuidas se

refiere, pues el que una transacción caiga en un determinado

servidor, debe implicar que todos los servidores implicados deben

echar atrás la operación errónea, lo cual puede resultar una operación

compleja y de envergadura. Además, en caso de caída los servidores

deben garantizar que todas las transacciones consideradas como

válidas son restauradas para garantizar la integridad de la información

en el momento del arranque de la máquina y antes de permitir el

proceso por parte de los usuarios (y es por ello por lo que los

servidores cuentan con el registro de LOG de transacciones).

2.5. PLATAFORMAS Y PROGRAMACIÓN

En este último punto comentaremos la importancia que tienen dos de

los parámetros relacionados con las plataformas disponibles para el

servidor y el grado de ampliación del mismo tanto de cara a su

implementación interna como en su capacidad de proporcionar API de

programación a los desarrolladores.

La escalabilidad y portabilidad del servidor será un factor a tener en

cuenta de cara a su adquisición o migración desde sistemas ya

existentes. Y ya no sólo de cara al motor del servidor sino de cara a

las plataformas de las herramientas de los clientes. Cuanto mayor sea

el rango de plataformas soportadas, tanto más universal será el

acceso al motor, lo que no limita a la empresa en cuanto a parque

tecnológico se refiere. En este punto, decir también que cuanto mejor

sea el soporte de migración y traspaso de información entre distintos

servidores, más se garantizará la integraci6n/migración de la

información ya existente, con el mínimo riesgo de pérdida de

información y el mínimo coste de implantación y desarrollo.

En cuanto al desarrollo, los servidores de datos deben proporcionar

las API necesarias para asegurar que los desarrollos que se lleven a

cabo puedan aprovechar los servicios de acceso y gestión de los

datos de la manera más eficiente y completa posibles. Y, además, no

deben limitar el desarrollo a la plataforma en la que se encuentra el

sistema, sino que debe ser capaz de dar soporte a los lenguajes

estándar de la Red como pueda ser Java, lo que garantizará una

integración total con los recursos de la Red.

2.6. EL SOPORTE HARDWARE NECESARIO

Lógicamente, sin un buen soporte hardware que proporcione los

factores de rendimiento necesarios para cumplir los objetivos de

acceso a la información, no podremos obtener las prestaciones

establecidas. En cuanto al procesador empiezan a aprovecharse al

máximo las arquitecturas SMP (Multiproceso simétrico). Los

servidores de datos serán capaces de distribuir la carga del análisis

dé las consultas, la ejecución de la programación de tareas y, como

no, el control de los accesos de múltiples usuarios al mismo tiempo.

Es requisito imprescindible contar con una buena cantidad de

memoria, pues una de las mejores maneras que, tienen los servidores

de proporcionar los datos de la manera más rápida posible es

mantener los sistemas de indexación, cursores y páginas caché en la

memoria del servidor. Lo que requiere de una enorme cantidad de

espacio libre. Ni que decir tiene que él disco duro es necesario que

disponga de almacenamiento de sobra si quiere ser capaz de albergar

varias bases de datos que son capaces de almacenar el nivel de

información diario (presente y futuro) que requiere el funcionamiento

de la empresa y sus reglas de negocio.

3. CONCLUSIONES

a. Ipv6

IPV6 aporta soluciones a los problemas de crecimiento de Internet.

Incorpora funcionalidades que mejoran su comportamiento en

aspectos de seguridad y configuración.

De acuerdo a los descrito anteriormente, se puede concluir que una

de las grandes diferencias entre el actual protocolo usado (IPv4) con

IPv6, es en la cantidad de combinaciones posibles que se pueden

obtener. En otras palabras, IPv6, ofrece 2^128 combinaciones, en

cambio IPv4, solo 2^32. Esto ampliaría enormemente el espectro de

objetos que puedan conectarse a la red, dando así, un mayor uso a

este medio y posiblemente descongestionar otros medios como son

las frecuencias de radio. IPv6 ofrece también, una notable mejoría

en disminuir el congestionamiento de las redes, como también

disminuir considerablemente el uso de NATs en redes, ya que estos,

ayudaban a ampliar las combinaciones posibles en IPv4.

b. Base de Datos

Las bases de datos forman el nucleó de las principales aplicaciones,

sitio web y servicios corporativos.

En todos los casos hay herramientas de gestión y control que

permiten verificar su funcionamiento y eventualmente corregirlo.

También se entiende que tiene una elevada capacidad y solidez

para administrar la información sin fallos ni errores.

4. RECOMENDACIONES

a. Ipv6

Favorecer la difusión y formación en Ipv6 en la comunidad

académica y empresarial.

Apoyar e impulsar las iniciativas del sector privado para el desarrollo

de nuevas redes, servicios y aplicaciones Ipv6.

Promover el uso de nuevas redes, servicios y aplicaciones Ipv6 en el

sector público, por parte de la administración pública.

Promover la implantación de Ipv6 por parte de las asociaciones

profesionales y empresariales.

b. Base de Datos

Las bases de datos sufren un desgaste del 3% mensual en

promedio, por lo que a fin de mantener un mayor porcentaje de

confiabilidad de los registros se deberá actualizar por lo menos 2

veces al año.

Elaborar un manual de uso donde se especifiquen las reglas de

captura de la base de datos. Ejemplo: abreviaturas, estandarización

de los registros, uso de mayúsculas, acentos, entre otros.

Identificar las diferentes variables que pudieran existir en un registro

para evitar su duplicidad.

Contar con una copia de respaldo que se ubique fuera de las

instalaciones de la empresa, a fin de garantizar su preservación en

caso de alguna eventualidad o desastre.

5. BIBLIOGRAFIA

a. Ipv6

http://es.wikipedia.org/wiki/IPv6

monografias .com/trabajos5/tipbases/tipbases.shtml

monografias .com/trabajos5/basede/basede.shtml

monografias.com/trabajos5/desor/desor.shtml

b. Base de Datos

inei.gob.pe/cpi/bancopub/libfree/lib607/cap01.htmet.gob.pe

elizabethpeguero.8m.com/enza.html

learnthenet.com/spanish/glossary/database.html

ipyme.org/sie/